Choose a software partner that practises continuous delivery because it decides how quickly, and how safely, a fix or a change can reach your users. A supplier that can release any tested change on any working day can repair a fault this week. A supplier whose releases are rare, manual events will ask you to wait for the next one, and each release will carry more risk. Continuous delivery sounds like a developer’s concern, but it is the thing that makes a supplier’s support promises believable.
What continuous delivery means
DORA, the software delivery research programme run by Google Cloud, defines continuous delivery as the ability to release changes of all kinds on demand quickly, safely and sustainably. In practice the software is kept in a state where it could be released at any time, and releasing it is a routine, mostly automated task.
Three related terms are often mixed up.
- Continuous integration. Every change a developer makes is merged into the shared code promptly, and an automated process builds the software and runs its tests each time. A change that breaks something is caught within minutes.
- Continuous delivery. Every change that passes those checks is ready to go live. Whether and when it does is a decision for the business.
- Continuous deployment. Every change that passes goes live automatically, with no person deciding. This suits some online products. Most business systems do not need it.
The automated route from a developer’s change to the live system is called a pipeline. Tools such as Azure Pipelines and GitHub Actions run it.
Continuous delivery does not mean your staff see a new version every day. A system that releases once a fortnight by choice, and could release tomorrow if it had to, is practising it.
Why it matters to the business paying for the software
Fixes arrive when you need them. If releasing is routine, a fault found on Tuesday can be corrected, tested and live on Wednesday. If releasing takes a weekend of manual work, the fix waits.
Each release carries less risk. A release containing three changes is easy to check and, if something goes wrong, easy to trace. A release containing three months of changes is neither.
You see real progress. Work that is finished is put where you can try it, on a test copy of the system, days after it was written. You are not relying on percentages in a status report.
The release does not depend on one person. When the steps are written into a script, anyone on the team can run them and the result is the same each time. A release that lives in one person’s memory stops when that person is on holiday.
Changing supplier is easier. A pipeline is a working record of how the system is built and released. A new team can read it and run it. This is why, when we take over a system, the first things we prove are that it can be built from its source code, released in a controlled way and restored from a backup.
DORA’s research supports the practical case. It reports that continuous delivery improves software delivery performance and reduces what it calls deployment pain, meaning how disruptive releases are for the people involved.
The link between delivery and support
A support agreement usually states how quickly the supplier will respond to a fault. As we explain in our article on service level agreements, a response is not a fix. What turns one into the other is the supplier’s ability to release.
Consider two suppliers who both begin work within an hour of a serious fault and both find the cause by lunchtime. The first runs its pipeline: the automated tests confirm that nothing else has broken, and the fix is live that afternoon. The second has to find the person who knows the release steps, build the software on that person’s machine and copy files to the server by hand in the evening, hoping nothing was missed. The response time in the two contracts is identical. The service is not.
The same applies to routine maintenance. Security updates are released promptly by a team for whom releasing is easy, and put off by a team for whom it is an ordeal.
What it takes on an older system
Many business systems were built before any of this was normal, and they are released by hand. That can be changed without rewriting them. An application on .NET Framework, or one with a large SQL Server database behind it, can be given the same basics as a new one:
- all the source code in version control, the system that records every change and who made it;
- a build that runs on a server, not on a developer’s own PC;
- automated tests around the calculations and rules that matter most;
- database changes written as scripts that are applied in order, not typed in by hand;
- a deployment that runs from a script and can be reversed.
Putting these in place is often the first stage of looking after an inherited system, because every later change depends on them. A manual release process is one of the commonest forms of technical debt, and one of the cheaper ones to pay off.
Questions to ask a prospective partner
You do not need to understand the tools. Ask about the behaviour, and listen for specific answers.
| Question | A good answer | A warning sign |
|---|---|---|
| How does a change get from a developer to the live system? | A sequence of named steps, mostly automated, that they can show you | ”One of our seniors handles that” |
| When did you last release a system like mine, and how often do you? | A recent date and a regular rhythm | Releases a few times a year, out of hours |
| How long from an approved fix to live? | Hours or days, with the checks described | ”It goes in the next release” |
| What happens if a release goes wrong? | A rehearsed way to reverse it, including the database | ”That has never happened” |
| Who can carry out a release? | Any of several people, from written steps | One named individual |
| Where can I try changes before they go live? | A test copy you can log in to | Screenshots |
These questions map onto the measures DORA uses to assess delivery: how often a team releases, how long a change takes to reach users, what share of releases cause a problem and how quickly a failed release is recovered. A supplier that tracks those figures for its own work will be glad to be asked. Our longer list of questions to ask a software supplier covers ownership, pricing and leaving a supplier as well.
If you already have a supplier, one request tells you most of what you need to know: ask them to release a small, harmless change, such as a corrected label, and watch how long it takes and how many people it involves.