My manager recently came to me and dropped an automation project on my lap (Yaaay!!). Without any context of the issues, the expectations of the project or any planning, the request was something I have seen many times over the years.
With the rise in the awareness of DevOps roles more than DevOps practices, this pattern is common these days. Hire a "DevOps", give him the task to "automate the world" and you will have CI/CD... eventually.
Wrong! You will have your processes automated, but if they were a mess to begin with, you just added another team and more tools and code, to the mix. Automation is an enhancement to processes not a replacement of them.
Let's take application configuration as an example. Using key management tools like vault and integrating them into your pipeline, you automate the configuration push to your application. Amazing!!! You just saved 10 minutes per deployment. But what about the underlying process? Configuration generation, secure sharing and tracking changes to it. You know, the process that takes days and several tickets across multiple teams to achieve.
Most teams do not focus on these "pre-deployment" processes since their visibility is low, so the impact is hidden. That is, until something goes wrong. Now you need to rollback but you didn't track the changes. You need to update the values, but you are not the one who generated them. And you need to do all this within a tight SLA and following all the requisite security protocols.
In short, the wrong problem was solved. And with the rise in the popularity of the micro-service architecture, the scale of this issue can be enormous (Recently worked with 76 different micro-services, configuration management was a nightmare until we adopted ConfigTree).
Processes are what need to be fixed, automations can always be developed and enhanced. The primary focus of any "DevOps Team" should not be the introduction of automated builds or CI/CD, but the re-engineering of the underlying processes.
The path to achieving the DevOps Transformation, does not start in code. It starts on a white board and is almost always a mess!!!
Top comments (0)