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.
 
(21 intermediate revisions by 3 users not shown)
Line 1: Line 1:
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 is a preview version of '''MSEC'''. The full version is available to [https://www.patreon.com/continuousdelivery Patreon supporters] at the Gemini level and above.''


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.
''[https://www.patreon.com/continuousdelivery Click here for details] on how to join the growing '''MSEC''' community.''
<br/>
----


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.  
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.


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]].
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 ==
 
That, in turn, says something else important, everything that we need to do to evaluate the [[Access Full MSEC via Patreon|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 [[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.
Line 20: Line 28:
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:  
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:  
<br>
<br>
* [[Unit Tests]]  
* [[Access Full MSEC via Patreon|Unit Tests]]  
* [[Acceptance Tests]]
* [[Acceptance Tests]]
* Validation
* Validation
* [[Integration Tests]]
* [[Access Full MSEC via Patreon|Integration Tests]]
* [[Version control]]
* [[Access Full MSEC via Patreon|Version control]]
* [[Sign-Offs]]
* [[Access Full MSEC via Patreon|Sign-Offs]]
* Any other tests or requirements to achieve releasability.  
* Any other tests or requirements to achieve releasability.  
<br>
<br>
Line 36: Line 44:
* Just a collection of tools and processes
* Just a collection of tools and processes
* For proving that new software is good
* For proving that new software is good
<br>


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 to realise its considerable benefits.
 
A Deployment Pipeline is a [[Access Full MSEC via Patreon|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 [[Access Full MSEC via Patreon|Cycle-Time]], [[Access Full MSEC via Patreon|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 ==
== Further Reading ==
* "[https://amzn.to/2WxRYmx Continuous Delivery]" - Book by [[Dave Farley]] & [[Jez Humble]]
* "[https://amzn.to/2WxRYmx Continuous Delivery]" - Book by [[Dave Farley]] & [[Access Full MSEC via Patreon|Jez Humble]]


* "[https://amzn.to/3gIULlA Continuous Delivery Pipelines]" - Book by [[Dave Farley]]
* "[https://amzn.to/3gIULlA Continuous Delivery Pipelines]" - Book by [[Dave Farley]]
Line 48: Line 56:
<youtube width="300" height="160">x9l6yw1PFbs</youtube>&nbsp;<youtube width="300" height="160">bHKHdp4H-8w</youtube>
<youtube width="300" height="160">x9l6yw1PFbs</youtube>&nbsp;<youtube width="300" height="160">bHKHdp4H-8w</youtube>


[[File:PipelinesWebinar.png|300x240px|link=https://courses.cd.training/courses/cd-pipelines-webinar]]
[[File:PipelinesWebinar.png|300x300px|link=https://courses.cd.training/courses/cd-pipelines-webinar]]
 
<br/>
----
''This is a preview version of '''MSEC'''. The full version is available to [https://www.patreon.com/continuousdelivery Patreon supporters] at the '''Gemini''' level and above.''
 
''[https://www.patreon.com/continuousdelivery Click here for details] on how to join the growing '''MSEC''' community.''
----


<big>'''<span style="color:white;background:#FFBE00;padding:4px">[[Main Page|<span style="color:white">Home</span>]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[Continuous Delivery|<span style="color:white">< Previous</span>]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[Access Full MSEC via Patreon|<span style="color:white">Next ></span>]]</span>'''</big>


<big>'''[[Main Page|Home]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[Main Page|< Previous]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[The Key Components of a Deployment Pipeline|Next >]]'''</big>
<!--
<big>'''<span style="color:white;background:#FFBE00;padding:4px">[[Main Page|<span style="color:white">Home</span>]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[Continuous Delivery|<span style="color:white">< Previous</span>]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[The Key Components of a Deployment Pipeline|<span style="color:white">Next ></span>]]</span>'''</big>
-->

Latest revision as of 15:08, 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.

An Example Deployment Pipeline

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:


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

Further Viewing

 

PipelinesWebinar.png



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.


Home     < Previous     Next >