How DevOps Teams Get Automation Backwards

The COVID-19 pandemic has lit a fire under DevOps teams to get serious about automation. In almost all cases, embracing automation is a wise move, but it’s one that should not be taken lightly. Automation won’t do you much good unless you’ve put in place the processes necessary to make it work. This is the reality that teams frequently confront as they move to introduce automated DevOps.

A prime example comes from CI/CD workflows. The transformative power of CI/CD is clear: automating deployments along a release pipeline saves an enormous amount of time, allowing you to achieve major cost savings and deploy to market much faster.

However, DevOps teams should delay putting in place CI/CD until they’ve established a robust development process. This includes choosing a release cadence, defining a branching strategy, establishing code review practices and quality control gates, and choosing a methodology for avoiding and addressing merge conflicts. Failure to define these processes can have disastrous effects. The fact is this period of training and gradual adoptions often means teams need to slow down before speeding up. Without proper consideration, this slowdown can cause teams to fall back on old practices, undermining the new process, yielding poor results, and ultimately causing the team to question the value of CI/CD.

Another important improvement that DevOps teams should strongly consider embracing is automated unit testing. But in the same way that CI/CD necessitates a robust development process first, automated testing only yields benefits if good development practices are instilled at the same time. For instance, it’s not uncommon to see teams hold up their test coverage reports as evidence of great test automation practices, but coverage reports don’t assess the quality of the tests. If tests don’t effectively exercise the logic of the underlying system, then the coverage reports are irrelevant, and the automation has no value.

Automated backups and precautions

The same precautions apply to automated backups. Do you know what data (and metadata) needs to be backed up in order to successfully restore? Do you know how it will be stored, protected and monitored? Does your storage plan comply with relevant statutes, such as CCPA and GDPR.  Do you regularly execute recovery scenarios, to test the integrity of your backups and the effectiveness of your restore process?

At the heart of each of the above examples, the problem is due in large part to a top-down mandate, and a lack of buy-in from the affected teams. If the DevOps team has a sense of ownership over the new processes, then they will be much more eager to take on any challenges that arise.

DevOps automation isn’t the solution to every problem. Automated UI tests are a great example of an automation solution that’s right for some types of organizations, but not for others. These sorts of tests, depending on frequency of UI changes, can be fragile and difficult to manage. Therefore, teams looking to adopt automated UI testing should first assess whether the anticipated benefits are worth the costs, and then ensure they have a plan for monitoring and maintaining the tests.

Finally, beware of automating any DevOps process that you don’t use on a frequent basis. If it’s not something you’re using often, there’s a good chance that things will have changed by the next time you need it, which will break the automation and force you to spend more time fixing it. A good alternative first step is to document the process thoroughly. If the documentation proves both helpful and stable over a long enough period, then it might be a good time to automate the process.

Ultimately, DevOps automation should only come after you have answers to some fundamental questions. Will automation speed up your processes, or will you end up with a brittle system that will demand constant attention and frequent, time-consuming fixes? Above all else you should ask: what problem am I trying to solve? Many problems can be fixed by automation, but in other cases automation will simply entrench whatever flaws exist in your current processes. In that case, your first order of business needs to be addressing those issues. At the end of the day, DevOps automation is a process of optimization, and as the venerable Donald Knuth once stated, “premature optimization is the root of all evil.”

Matt Dickens is Chief Product Officer and co-founder at Gearset.