@michaelneale Oh, God no! That would never work!—
"Robert's just this guy, you know..." Watkins (@twasink) April 19, 2018
Yes, it’s shocking – not every technique is universally applicable. In this post, I want to explore some of the reasons why you may not want to do Continuous Deployment.
First, though, let me make something clear: Continuous Deployment is not a bad thing to do. There are many situations where it is the ideal thing to do, and many more where moving towards Continuous Deployment is a good idea (even if you fall short and don’t ever achieve it). It’s just not 100% applicable.
Why wouldn’t you use Continuous Deployment?
Here’s some reasons not to use Continuous Deployment; there are others.
Work In Progress (WIP)
WIP is a big one. In order to use Continuous Deployment – or even less extreme versions, such as the ‘always work on master/no feature branches’ crowd – you need to be comfortable with having unfinished work in your production code. That takes a lot of support infrastructure to make happen – mainly in the form of Feature Toggles.
There’s a lot of benefit involved in limiting Work In Progress, and reducing how long work stays in-progress, but it can’t be eliminated for any development pipeline that involves more than one person. You will need to be very comfortable with managing Feature Toggles to be able to do Continuous Deployment.
(Sidebar: it’s very easy to not limit WIP when using Feature Toggles. It takes discipline to go through and turn the features on for all users, and the WIP is not finished until the Feature Toggle is removed. The worst part is when you end up with multiple Feature Toggles in the same area. But I’ll save that rant for another post)
If you are going to do Continuous Deployment, you better have confidence in your automated testing for regression testing. Now, automated testing is an area where it’s always good to invest – but you shouldn’t think of doing Continuous Deployment until you’ve done release after release with zero bugs being found via your pre-release testing process.
You also need to make this pretty fast. If you’re doing Continuous Deployment, you’re essentially pushing to production as a result of every commit to the master/release branch. This will happen via a build pipeline that will test & verify the changes before releasing – and if this gets stopped at the very last stage, it will get rolled back. If this takes time, there will be other changes in the pipeline – and they all need to get rolled back and re-committed.
If your build pipeline takes hours, you’re not going to get benefit from Continuous Deployment.
This is a bit overlooked in a lot of the stuff I’ve read promoting Continuous Deployment, but… not all deployment environments are amenable to Continuous Deployment in the first place.
Serverside and web development is (very) amenable. But it’s not the be-all and end-all of software. There’s other platforms, such as mobile and desktop. There is software that is hard to update, such as embedded software in devices that aren’t connected on-line. There is software used in regulated environments, where new versions must be certified before being released.
If you can’t just deploy a change anytime you want to, you can’t do Continuous Deployment.
Note that even in these environments, you can still get a lot of benefit in having a master branch that’s ready to be released all the time.
We write software to be used by people. Some people don’t cope well with change. Especially when you write software used by people to do their work, change management is a big deal. I’ve known users of software to go into rages because of a screen change, because it reduced their productivity because their muscle memory was now broken.
Frequent change can seriously piss your userbase off. You can manage this with Feature Toggles – deploying the software but not turning features on – but if you have features that stay turned off for months while you get ready to roll them out to users, you have WIP that builds up, and you lose a lot of the value of Continuous Deployment.
Finally – doing Continuous Deployment can be expensive. It takes support infrastructure, discipline, and vigilance.
If your rate of delivery isn’t that high, or your customers don’t want continuous updates, or for any other reason where you just can’t get the value, then it’s just not worth doing.
There’s nothing in this post that represents some great insight. It boils down to: “Don’t just believe the hype; stop and consider”.
If you can do it, do so. If you can’t, consider progressing towards it. Start somewhere where you have control and the impact is low – maybe refresh a test environment on a daily basis, or produce nightly builds that you can push out to mobile devices via TestFlight.