When continuous deployment isn't possible

Sometime's it's impossible to deploy frequently. But don't let that keep you from continuous delivery!

Last Thursday I made the case for continuous delivery at Agile Tour Vienna 2022. And one of the people in attendance brought up a concern:

Sometime’s it’s impossible to deploy frequently.

Yes. Yes it is.

But that doesn’t mean you can’t do continuous delivery!

What’s the difference?

Continuous Delivery is the practice of continuously and automatically delivering a software package so that it is ready to release on demand.

In contrast, Continuous Deployment takes things one step farther, and also deploys the software into production.

It is my belief that continuous delivery makes sense for practically all software projects. I’ve yet to find a situation where it’s not technically feasible.

However, there are many times when it doesn’t make sense (either technically, logistically, or from a business standpoint) to deploy continuously. Here are a few:

  • You sell a mobile application. Users don’t want to download 300 updates per day.
  • You sell any software that users install. Users tend to like the option to do upgrades at a time they choose.
  • Zero-downtime upgrades aren’t technically possible. OS updates, ROM flashing, or a handful of other scenarios can make upgrades inherently disruptive.
  • You are contractually obligated to do updates during a specific maintenence window.
  • Your software is installed on equipment with poor or no network connectivity. Microcontrollers in a manufacturing plant, or a rover on Mars, could be examples.

Even in the most extreme examples here, continuous delivery still makes sense to me. And in fact, continuous deployment to a production-like test environment usually makes sense, too.

Bottom line: Don’t let “our customers don’t want 300 updates per day” be a reason not to operate a perfect continuous delivery process.

Share this