Why Continuous Deployment matters to business
“Continuous Deployment” (CD) has become a hot topic amongst development teams recently. At Songkick, we moved to CD three years ago. It’s been a revelation for the development team, but what does it mean to the broader business?
What is Continuous Deployment?
Traditional software development — especially before the web — was organised around releases. You would work on a set of features, writing code and testing it until everything worked. Then you’d release all of these changes to your product in one go. Back when software was delivered on floppy disks or CD-ROMs, you might do 1 or 2 releases every year. Really fast companies released new versions every quarter.
It was a painful process for users to upgrade to the latest version. They had to get the software sent to them, in the post, then install it slow physical media. No-one wanted to do that every week. So releases were infrequent and were the result of months of work.
With the advent of the web, it became possible to update more frequently and usually automatically. Web software like Google Docs updates every now and again without you having to do anything. Nice.
When web software updates, users mind less if it updates more often. If you start releasing updates every month or every couple of weeks, each release becomes smaller. After all, you have less time to develop features if you only have two weeks rather than six months.
Doing lots of smaller, more frequent releases has a number of rather pleasant effects:
- Quality goes up — because you are making smaller changes, each release is smaller and easier to test.
- It is easier for users to learn — turns out people are quite good at dealing with small, frequent changes. They don’t like having to learn hundreds of new features all in one go; a steady feed of small changes is much easier to deal with.
- Faster development — developers are more efficient working on smaller changes because they have less context that they need to hold in their heads while working. They can focus on one or two features, and not worry about how hundreds of different features interact.
Continuous Deployment takes this trend to its logical conclusion. Instead of trying to release sets of changes every couple of weeks, you aim to release multiple times per day. You break features down into the smallest possible chunks, and as soon as a chunk of code is finished, you deploy it onto your production systems and it is live before users.
At Songkick, we went from releases every 2–3 weeks to doing 10–15 releases every day.
Why is CD good for developers?
Continuous Deployment makes a huge difference for developers. Here are some of its effects:
- You develop even faster — with CD there is much less overhead. As soon as your code is developed, your users are using it. If there is a bug, its in the code you just wrote, so you never have to stop what you are doing and go back to code that went live a week ago.
- Quality rises even further — the emphasis on tiny changes means that if a bug occurs its very easy to find and fix — it has to be in that tiny change you just made.
- Tiny changes are good for users — the changes are so small and frequent that they are often invisible to users. Their product just gets gradually better and better and they rarely have to stop and learn something new.
There’s a lot more to doing CD well, some of which I’ve talked about before, if you’re interested in the details.
Why is CD good for business?
With CD, productive developers deliver higher quality products to happy users. That sounds like a recipe for business success. It is. It really is.
But there are other business benefits of using CD:
- Flexibility— because your development team is making constant small changes, its relatively easy to re-priortize what they are working on. You don’t have to wait for two weeks (or 6 months!) for the next release cycle, people can usually wrap their current tasks within a day and work on something else.
- Of course, there are still switching costs. If I’m currently deep in writing highly-distributed Go microservices and you want me to work on a JavaScript client application feature, it will take me time to make the switch. But, if I’m currently working on a web app feature and you want me to focus on a different feature of the same app, I can do so quickly.
- Experimentation — CD promotes a highly experimental approach. It is relatively easy to implement a proper A/B testing regime on top of CD. This allows you to quickly develop and deploy alternative versions of a feature and see which performs better with real users.
- Your product strategy can now be data-driven. For many product questions, you no longer need to guess, you can just build a different version of a feature and see whether it improves your business metrics.
- Innovation —A team that is used to quickly shipping experiments and getting back user-validated results fast, will soon find itself naturally innovating. The team will be constantly generating new ideas and testing them out.
- These innovations start at the micro level, with the team experimenting with relatively small changes. But innovation is addictive and they will soon be coming up with bigger ideas that could make huge changes to your business.
- Costs become clear — traditional software development suffers from many problems, but perhaps the biggest is that it’s impossible to accurately estimate how long a large release will take (which is why software is almost always late) and therefore it is almost impossible to understand the costs involved.
- By breaking down large releases into a continuous flow of small changes, it becomes much easier to measure progress. The costs are exposed, rather than hidden. Also, smaller changes are easier to prioritize, so you are always working on the next most important task, which makes it easier to stop when you’ve reached the value you wanted.
- You still can’t estimate how long a large project will take, but you can measures its costs and impact as you go, rather than waiting months or years for it to complete.
Continuous deployment is fundamentally changing how software is being built. It makes software development faster, leads to higher quality products and happier teams and customers. It gives you more visibility into progress and costs. It helps you be more innovative. Why wouldn’t you want all that?
Further reading
Interested in learning more about CD? Here are some good starting points:
- Timothy Fitz’s “Continuous Deployment at IMVU”, one of the first descriptions of CD in practice
- Chad Dickerson’s “How does Etsy manage development and operations?” — how Etsy does CD at scale. Another early and influential post.
- Video of my presentation on “How Songkick Experiments” at LeanConf 2013
