Why Continuous Delivery is so important
Scrum is a (pretty) good framework for managing requirements, how they move into and out of backlogs, and how we inspect and adapt the outcome of those requirements. But one of its weaknesses is it has basically nothing to say about engineering practices. (As opposed to say Extreme Programming).
One of those engineering practices is Continuous Delivery, or CD. This discipline (and some related activities, like Continuous Integration and Test Automation) is actually a very important part of Agile, although it’s not immediately clear why.
This article will explain why Continuous Delivery is so important:
- Continuous delivery enables developers to verify software updates before deploying them to customers, reducing risk
- CD lets you catch defects earlier in the software development lifecycle, saving money
- It reduces manual work in deployment and operation activities, which reduces errors and rework
- It reduces pressure on operations and and testing teams
- Continuous Delivery enables fast feedback loops, which lets teams iterate based on learning.
I will now go through these points in more detail.
Is Continuous Delivery in the Agile Manifesto?
The agile manifesto
Continuous Delivery isn’t to be found in the four values of the Agile Manifesto.But if you look a little deeper, it’s right there, in the twelve principles.
It’s actually the first of those principles. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.
There’s also this, in the third principle: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”.
So continuous delivery has always been core to the ideas of agile software development.
What is Continuous Delivery anyway?
In the excellent book “Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation”, Martin Fowler defines Continuous Delivery as “a software development discipline where you build software in such a way that the software can be released to production at any time”. How can you make sure your software is ready to be released to production at any time?
Continuous Delivery is an important part of agile software development
You test the hell out of it, you integrate everyone’s changes every day, and you automate as much as possible. Continuous Integration is seen as a necessary precursor to Continuous Delivery, which is why you will often see the phrase CI/CD (Continuous Integration / Continuous Delivery).
You have to build quality in from the beginning, for every story, for every feature. If you only test for quality at the end of a cycle (or series of cycles), you’re not able to push the software out. So software can’t go out anywhere near production without being subjected to a barrage of intensive automated tests, run every day (or more frequently).
So why is continuous delivery important?
Let’s go through the reasons why continuous delivery is important.
Continuous Delivery enables developers to quickly verify changes
By definition, any team doing continuous delivery is always ready to release the latest version of their software. So you are able to quickly verify changes, both pre and post deployment. This reduces risk and increases confidence. And reduces cycle time, since you don’t have to wait for slow manual testing for your software changes to go live.
Of course, you have to do investments in automated testing to enable this. But it will pay off in many ways, described further below.
Continuous Delivery lets you catch defects earlier
Teams doing CD run tests very quickly and frequently. This means they capture defects quickly and early, rather than late. And the cost of fixing or remediating defects increases exponentially, the later you find and fix them. This article explains it in more detail.
So while it costs money to build up a CD capability, it can start saving you money right away, by catching defects earlier. When it is cheaper to do so.
CD reduces manual work and errors in releasing
When most firms to a software release, there is a lot of manual work and mucking around. This means uncertainty, risk, and errors. The better approach is to automate everything. Not just testing, but configuration, deployment, and so on.
The more automation, the faster things move, and the less chance for errors and rework, and the more controllable and auditable everything is. And the easier it is to roll things back.
I’ve worked on big releases for financial services firms that had runsheets with 500 or more line items on them. That went for pages and pages and pages. These releases involved the work of 100 or more people and went for 24 or sometimes 48 hours. There were a nightmare to coordinate. And when things went wrong (and they often did), it was very hard to troubleshoot, fix or roll back.
With automation, most of those problems go away. As the Continuous Delivery book says, “releasing software should be boring”. Push a button and watch some numbers flicker on a screen. Get a coffee and come back and see if it’s finished. That sort of boring.
Continuous Delivery reduces pressure on operations teams
Nobody wants to be on that Operations team, getting scary calls or text messages at 2 in the morning. Telling you to set up a bridge call and summon in the team for a long night. This stuff isn’t fun for anyone.
Many firms doing DevOps adopt continuous delivery techniques
Remember, releases should be boring. You want to move pressure off these people. The people building software should take responsibility for it working. That doesn’t mean we want them taking calls at 2 in the morning! It means nobody should be doing that.
Continuous Delivery means operations teams (if you have them, or you are maybe moving to DevOps?) are focused more on monitoring, upgrading, and continuous improvement. Good old fashioned service management stuff. Not fixing leaks and firefighting.
CD means faster feedback loops
But there’s more to it than that. Continuous Delivery is important to agile because being able to release at any time means you can close your feedback loops.
If your software has good metrics built-in (and it should), you can quickly get information from your customers about what they value in your software. But you also need to be able to respond to that information.
There’s no use collecting information daily if it takes you six months to put out a software release based on that information! Your competitors will have leap-frogged past you in that time.
Amplifying feedback loops is in fact one of the three core principles of DevOps, and rightly so. It is crucial to any product-based organization and is a core enable of business agility.
Continuous Delivery enables the fast feedback loops that lets firms measure, learn and adapt quickly and safely.
Continuous Delivery enables quality and reduces technical risk
You can’t have quality without automated testing, continuous integration, and continuous delivery. You need to be regularly integrating and testing your code to ensure there aren’t conflicts. And to avoid the infamous “integration hell” suffered by waterfall projects, with big late code merges.
The quicker you can merge your branches, test your code and get it out there, the quicker you can reduce risk, find and fix defects and stay on top of quality issues. It’s that simple.
Any project manager should understand the value of building in quality and reducing technical risk.
Automation and consistency
It’s not just about reducing your time to deliver and improving speed. Continuous Delivery requires automation, and automation results in consistency.
If your infrastructure setup, application build and install and configuration are all automated, that means less errors, less rework and more predictability. The processes will be become more simplified and streamlined. Which means less pain and risk for everyone.
Ideally, you can end up virtualising most or all of your technology stack. And move to “Infrastructure as Code”, or “IAS”. Then, creating or destroying entire environments can be a few lines of config in a text file and firing off a command in a shell.
Better customer experience
If you are doing continuous delivery, you are not only testing and deploying new versions faster, but fixes too. So when errors and bugs creep into production, you can get fixes built, tested and deployed in hours, not in weeks. This will reduce complaints and improve customer satisfaction, which will flow onto a better bottom line. So you should see DevOps as an investment, not a cost centre.
Summary
In summary, continuous delivery is super important to any organisation on an agile journey. It is baked into the agile manifesto and is “table stakes” for any serious technology company.
It is going to cost money, like any investment, but will pay off well if you take it seriously and do it well. Because it increases quality, reduces risk, removes errors, enables fast feedback, and delivers value to customers.
Frequently asked questions on why continuous delivery is so important
What are the benefits of continuous integration and continuous delivery?
The continuous delivery benefits are described above. The main advantages of CI (continuous integration) is that it reduces the size and risk of integration issues. Since developers are integrating their code quickly and frequently. This avoids the “integration hell” that you might have seen or heard about.
What are three advantages of having a CI/CD pipeline?
A CI/CD pipeline:
- reduces waste by removing errors and automating steps
- provides a shorter review time, since changes are smaller and have automated tests
- better code quality – since everything is continually tested and integrated, code quality will increase and defects will go down (they are also caught earlier, which makes fixing them cheaper).
This video explains some of the benefits of Continuous Delivery in more detail.
