Deployment Pipeline
The objective of a Deployment Pipeline is to provide clear, fast, feedback on the quality of our work. The most definitive statement on the quality of our work, before it reaches production, is “are we ready to release?”. This means that the clearest signal that a Deployment Pipeline can send is on the releasability of our changes.
This simple idea has some profound implications. It means that the scope of a Deployment Pipeline is, ideally, a releasable unit of software, something that, if the Pipeline says it is good, we are happy to deploy into production with no further work.
That, in turn, says something else important, everything that we need to do to evaluate the “releasability” of this deployable unit of our system is within the scope of the Deployment Pipeline.
Basic levels of automated testing are assumed, we’ll talk more about what counts as “basic” soon, but if, you need to go beyond the basics, if your system needs performance testing, security testing, scalability testing, resilience testing or needs to be regulatory compliant, then these too are all within the scope of the Pipeline.
If you are thinking that these pipelines sound as if they may sometimes be complex then you are right. The secret though, is to start with small steps and gradually evolve this level of sophistication as you go.
This focus on making progress in small steps is true wether you are starting from a blank-sheet, or implementing a Deployment Pipeline for an existing, complex system.
Figure 1 - Example Deployment Pipeline
Continuous Delivery is about optimising the development process:
“from idea to valuable software in the hands of our users”,
and we want to achieve this repeatably and reliably.
The Deployment Pipeline is a machine that organises our software development work, to go “from Commit, to Releasable Outcome”, repeatably and reliably, quickly and efficiently. It includes any and all steps that are required for new software to be releasable, i.e: all unit tests, acceptance tests, validation, integration, version control, sign-offs and any other tests or requirements to achieve releasability. When new code has completed the transit through the pipeline, there should be no more work to do and the software can be safely released into production.
The Deployment Pipeline is NOT:
| only an automated build, test and deploy workflow | |
| a series of separate pipelines for build, test and deployment | |
| just a collection of tools and processes | |
| for proving that new software is good |
A Deployment Pipeline is a falsification mechanism, where we can fix, and learn from, failed tests quickly. It is a platform where we can test ideas and make changes safely. The pipeline enables the measurement of test results, and produces data about cycle-time, stability and throughput, which we can use to make evidence-based decisions. The Deployment Pipeline supports development teams in producing high-quality software, and requires their commitment to effective behaviors, keep the pipeline functioning and to realise its considerable benefits.