Difference between revisions of "Deployment Pipeline"

From MSEC
Jump to navigation Jump to search
Access restrictions were established for this page. If you see this message, you have no access to this page.
Line 12: Line 12:




[[File:/Users/davef/Desktop/Pipeline1|frameless|The Deployment Pipeleine]]
[[File:images/Pipeline1.png|frameless|The Deployment Pipeleine]]

Revision as of 17:38, 12 July 2021

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.


The Deployment Pipeleine