What is Continuous Delivery?
Continuous Delivery is a software engineering approach in which teams produce software in short cycles. It’s about the ability to get changes of all types into production, safely and quickly in a sustainable way. It aims to build, test, and release software with greater speed and frequency. This helps reduce the cost, time, and risks.
Why continuous delivery?
The practices at the heart of continuous delivery help us achieve several important benefits:
- Low risk releases: The primary goal of continuous delivery is to make software deployment painless, low-risk events that can be performed at any time, on demand.
- Faster time to market: when teams work together to automate the build, deployment, environment provisioning, and regression testing processes, developers can incorporate integration and regression testing into their daily work and completely remove these phases. We also avoid the large amounts of re-work that plague the phased approach.
- Higher quality: When developers have automation tools that discover regressions within minutes, teams are freed to focus their effort on user research and higher-level testing activities.
- Lower costs: any successful software product or service will evolve significantly over the course of its lifetime. By investing in build, test, deployment and environment automation, we substantially reduce the cost of making and delivering incremental changes to software by eliminating many of the fixed costs associated with the release process.
- Better products: Continuous delivery makes it economic to work in small batches.
- Build Quality In: It’s much cheaper to fix problems and defect if we find them immediately—ideally before they are ever checked into version control, by running automated tests locally. Creating and evolving feedback loops to detect problems as early as possible is essential and never-ending work in continuous delivery.
- Work in Small Batches: In continuous delivery, we take the opposite approach, try and get every change in version control as far as we can towards release. Working in small batches has many benefits. It reduces the time it takes to get feedback on our work, makes it easier to triage and remediate problems, increases efficiency and motivation, and prevents us from succumbing to the sunk cost fallacy.
- Computers Perform Repetitive Tasks, People Solve Problems: The goal is for computers to perform simple, repetitive tasks, such as regression testing, so that humans can focus on problem-solving.
- Relentlessly Pursue Continuous Improvement: The best organizations are those where everybody treats improvement work as an essential part of their daily work, and where nobody is satisfied with the status quo.
- Everyone is Responsible: In high performing organizations, nothing is “somebody else’s problem”. Developers are responsible for the quality and stability of the software they build. Operations teams are responsible for helping developers build quality in. Everyone works together to achieve the organizational level goals, rather than optimizing for what’s best for their team or department.
Continuous delivery rests on three foundations: comprehensive configuration management, continuous integration, and continuous testing.
Automation plays a vital role in ensuring we can release software repeatably and reliably. One key goal is to take repetitive manual processes like build, deployment, regression testing and infrastructure provisioning, and automate them. In order to achieve this, we need to version control everything required to perform these processes.
We have two overriding goals:
- Reproducibility: We should be able to provision any environment in a fully automated fashion, and know that any new environment reproduced from the same configuration is identical.
- Traceability: We should be able to pick any environment and be able to determine quickly and precisely the versions of every dependency used to create that environment. We also want to to be able to compare previous versions of an environment and see what has changed between them.
These capabilities give us several very important benefits:
- Disaster recovery
- Higher quality
- Capacity management
- Response to defects
CI (continuous integration) follows the XP (extreme programming) principle that if something is painful, we should do it more often, and bring the pain forward. Thus in CI developers integrate all their work into trunk (also known as mainline or master) on a regular basis (at least daily). A set of automated tests is run both before and after the merge to validate that no regressions are introduced. If these automated tests fail, the team stops what they are doing and someone fixes the problem immediately.
Despite these barriers, helping software development teams implement continuous integration should be the number one priority for any organization wanting to start the journey to continuous delivery. By creating rapid feedback loops and ensuring developers work in small batches, CI enables teams to build quality into their software, thus reducing the cost of ongoing software development, and increasing both the productivity of teams and the quality of the work they produce.
Once we have continuous integration and test automation in place, we create a deployment pipeline, In the deployment pipeline, every change is effectively a release candidate. The job of the deployment pipeline is to catch known issues. If we can’t detect any known problems, we should feel totally comfortable releasing any packages that have gone through it. If we aren’t, or if we discover defects later, it means we need to improve our pipeline, perhaps adding or updating some tests.
Our goal should be to find problems as soon as possible, and make the lead time from check-in to release as short as possible. Thus we want to parallelize the activities in the deployment pipeline, not have many stages executing in series. There is also a feedback process: if we discover bugs in exploratory testing, we should be looking to improve our automated tests. If we discover a defect in the acceptance tests, we should be looking to improve our unit tests (most of our defects should be discovered through unit testing).