Difference between revisions of "Deployment Pipeline"
| Line 5: | Line 5: | ||
---- | ---- | ||
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. | The objective of a Deployment Pipeline is to provide clear, fast, [[Access Full MSEC via Patreon|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 [[Access Full MSEC via Patreon|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. | This simple idea has some profound implications. It means that the scope of a Deployment Pipeline is, ideally, a [[Access Full MSEC via Patreon|Releasable Unit of Software]], something that, if the Pipeline says it is good, we are happy to deploy into production with no further work. | ||
== A [[Deployment Pipeline]] Defines a Releasable Outcome == | == A [[Deployment Pipeline]] Defines a Releasable Outcome == | ||
| Line 13: | Line 13: | ||
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. | 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 Automated Testing]] 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]]. | Basic levels of automated testing are assumed, we’ll talk more about what counts as [[Access Full MSEC via Patreon|Basic Automated Testing]] soon, but if, you need to go beyond the basics, if your system needs [[Access Full MSEC via Patreon|Performance Testing]], [[Access Full MSEC via Patreon|Security Testing]], [[Access Full MSEC via Patreon|Scalability Testing]], [[Access Full MSEC via Patreon|Resilience Testing]] or needs to be [[Access Full MSEC via Patreon|Regulatory Compliant]], then these too are all within the [[Access Full MSEC via Patreon|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. | 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. | ||
Revision as of 15:06, 17 January 2023
This is a preview version of MSEC. The full version is available to Patreon supporters at the Gemini level and above.
Click here for details on how to join the growing MSEC community.
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.
A Deployment Pipeline Defines a Releasable Outcome
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 Automated Testing 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:
- Unit Tests
- Acceptance Tests
- Validation
- Integration Tests
- Version control
- Sign-Offs
- 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 & Throughput, as well as many other aspects of software development. This allows us to use this information 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 realize its considerable benefits.
Further Reading
- "Continuous Delivery" - Book by Dave Farley & Jez Humble
- "Continuous Delivery Pipelines" - Book by Dave Farley
Further Viewing
This is a preview version of MSEC. The full version is available to Patreon supporters at the Gemini level and above.
Click here for details on how to join the growing MSEC community.