We can't afford automation right now
December 26, 2021Avoid a big up-front investment in automation by building it piece by piece, as needed.
You’ve just joined a new team, and their software is a mess. They do manual deployments, which take a few hours. Rollbacks are even worse. After you write a 3-line fix, it takes several hours to fire up all the test instances to test it.
“If only they had automated these things!” you think to yourself.
Now jump back in time 6 months or a year, and imagine you’re on the same team. You’re under time pressure. You’re not sure if the launch will be a success. And there are a thousand other things going on. Could you see yourself saying “We can’t afford automation right now”?
How can you balance the need for speed with the desire for automation?
Here’s my simple approach:
- Everything that you do more than once or twice should be documented, to guide a fellow human through the process. This document should be updated every time things change, or it’s found to be incomplete or unclear. Think of this as “Manual automation”. Remember: humans are Turing-complete.
- Look for opportunities to automate small parts of the task. Focus on error-prone or toilsome tasks. If your deployment involves typing a long
tarcommand, turn it into a shell script. If the build process requires 5 different commands in sequence, each of which takes 5 minutes to execute, turn it into a script so you don’t have to sit at your terminal the whole time.
Bit by bit your “manual automation” checklist will turn into a set of automation scripts. All the while, you’ll have complete confidence that you’re only automating tasks that warrant automation, because they provide an imediate return on investment.
A GitFlow story
A team I recently started working with has been using GitFlow. Until last week.
Adventures In DevOps 093: Deconstructing the Minimum Viable Continuous Deployment
The panel jumps in and discusses the Minimum Viable Continuous Deployment from the manifesto on the web and discuss where they agree and disagree with the requirements listed there and clarify some of the ideas in the document.
Different models of CI/CD
There's almost always more than one way to do something. What workflow does your team use for CI/CD?