On a couple of subjects, recently, I’ve been finding it odd to debate why “modern” software engineering techniques such as Test Driven Development and Continuous Deployment, are being described as a cost, rather than a benefit.
Is this some backlash similar to that experienced by factory workers when robots came in:
- You can’t automate testing, what about good honest manual testers? What are they going to do?
- You can’t expect your code to follow design patterns – it’s not like the good old days of nice monolithic functions
- Why are you writing test code, write proper code – I don’t pay you to maintain non production code
- Where’s the return on investment for the time spent creating code deployment pipelines – we can deploy manually easily
It’s Like People Have Forgotten Why
There must be a reason why people have spearheaded CI/CD and TDD. Why do we automate the pathway from keyboard to live with rapid feedback loops?
By asking where the business value is in this pipeline, there’s a reversal of the burden of proof (in my opinion at least). If you map the process (using Value Stream Mapping) with delays and handoffs in it, then any gap is “waste” in lean terms, and usually the answer pops out that we need to automate things to go faster.
But are there exceptions? And does it apply to you in your current project?
A better question is this. Is there a risk or time sink caused by not having a pipeline to deliver value-adding features safely to live? If the answer is that it’s zero risk and zero time, then you need to focus on features and forget pipelines and tests and other stuff.
Perhaps we’re a small break-fix team with a rock solid and easy to manage product. Perhaps this isn’t the time to add anything else and it won’t make a different. It’s possible.
I’m yet to see a release process that’s improved by being a manual process, though. Even in relatively trivial cases.
Though when something’s trivial, one shouldn’t over invest in it.
Another measure you can use of your current process effectiveness is the ideal batch size for a release. Do you need to save up features until the next release window? or can you release each feature easily when it becomes available?
If you’re saving up features, then your value stream mapping will illustrate a fairly long time to market for the earlier features, which is a form of cost you’ve not factored into your thinking.
Another metric is the sense of danger in each release. Does someone have to carefully follow a lot of steps and risk an outage? Or is it easy and bullet-proof?
If you’re in the latter camp, then well done.
You literally might not need automation… but in my experience, it’s a world ahead of the historic alternatives. However, the process of getting there may be long and you shouldn’t stop the development process just to achieve automation.
Incremental steps are a good way forward.
Where Do I Use and Avoid Automation?
My personal static websites are deployed to S3 from GitLab via a tiny code pipeline that literally runs
aws s3 sync – I do this because I want to be able to make changes and not have to remember the settings/commands/paths. It was too easy to automate NOT to automate it.
My open source projects use CI on all branches. I still have a manual release process. It goes a bit wrong every time I try it, but I’ve made only a handful of releases in total, and I’ve not yet decided how I want automatic release to work in terms of WHEN to release and HOW to decide version numbering.
If I planned on many future releases, or if I hit a point of releasing several times in a given month, I would automate these. To a degree, I feel like I’m still learning how I would want to release the software.
It Applies to Everything
All projects we’ve worked on in my most recent freelance project have been using CI from the get go, even projects we’ve imported. Similarly, manual deployment has only been attempted in prototypes, with immediate switchover to scripting in order to create consistency and repeatability. The time involved in doing this has been measurable in hours.
I literally can’t see how someone would start a project without putting CI/CD high up the list of things to get working. And I would actively throw away a technology that resisted automated deployment.