“Bring The Pain Forward” — DevOps Bootcamp
“Bring the pain forward” is the main value which i get from this section of Bootcamp in Gojek. What does “Bring the pain forward” mean? Before we are talking deeper let me tell you a little bit what i learn from previous Bootcamp, Core Engineering, which also related to this term.
Preface From Previous Bootcamp
One of the key value in Core Engineering Bootcamp is to do Test-Driven Development. Why we should do that? Maybe you can Google it and you will find many reasons why we should do that but for me the main reason to do that is to find out “bug” as soon as possible. As we find “bug” as soon as possible, we can fix it as soon as possible before it become bigger and bigger for us to handle.
TDD will “Bring the pain forward” to us especially when we also do CI/CD where we should continuously integrate our code with others for each commit and continuously deploy our code to production. Wait, if i need to integrate our code with others for each commit then it would be pain in the a**. It will not be a problem if we can delegate most of that repeatable and painfull task to some tools and automate that, so that DevOps will be your savior.
What? DevOps?
In DevOps Bootcamp, i learn about using CI tools to help us automate integration process so that as soon as we commit our code it will be automatically integrate with other’s code. Automating integration process with CI tools will make us less thinking about it and can be more focus to build high quality code. DevOps could make developer life “easier”.
We also should make sure that our CI tools environment is as close as production environment so that CI can integrate our code and run the spec as if it is in production. The goal of doing that is to simulate what will happen in the production so that when the spec is failing, it can be an early warning for us before we push it to production, again “Bring the pain forward”.
Not only as an early warning, when we make our CI tools environment as close as our production environment, we can build our code and download all of dependencies in CI environment as if it is built and downloaded in production environment so that our production doesn’t need to run the build anymore and just run the build result with all of the dependencies from the CI tools. It will “Bring the pain forward” to CI tools instead of in production, as result downtime of production will be decreasing when we deploy our code because it doesn’t need to build and download all the dependencies by itself.
For the deployment stage we still do it manually by downloading the build result from CI to the production. It will not become a problem if we only deploy it to just one or two production server but what if we need to deploy it to ten or twenty production environment? It will be another pain to us.
So far i like the approach of this section which is “Bring the pain forward”, where we feel the pain first and then come with solution to solve it, so that we can understand more why we should do that not only just do it without knowing why we do that and that is the most important thing, at least for me.
DevOps Bootcamp session still have four days left and i wish i could learn about how to setup continuous deployment tools with feel-the-pain-first approach too or even expose it more explicitly why we should do that because sometime it still feel implicitly stated.