<commit_before>---
layout: post
title: "Modeling Deployment Pipelines: The Importance and Principles of Continuous Delivery Pipelines"
type: post
author: <NAME>, Product Manager at GoCD
excerpt: "The path from commit to production involves numerous moving parts, (like multiple code and asset repositories, automatic and manual handoffs, unit tests, integration tests, acceptance tests, performance tests, security tests, etc.) and time that it takes to execute all of these elements. You need a way of modeling your workflow so that people can see, understand and talk about it. This is where CD pipelines come in."
title_tag_of_header: "Importance and Principles of CD Pipelines | GoCD Blog"
meta_description: "You need a way of modeling your workflow so that people can see, understand and talk about it. This is where CD pipelines come in. "
meta_keywords: "GoCD, continuous delivery, goforcd, open source, software, contribute to open source, agile continuous delivery, code contribution, Go"
summary_image: "/assets/images/blog/migrating-snapci-gocd/snapci-migrating-gocd.jpg"
draft: true
---
In an ideal, magical world, your end-to-end deployment from a commit to production looks like this:

<%= image_tag 'blog/importance-cd-pipelines/magic.jpeg', :alt => 'Magical Deployment', :title => 'Magical Deployment Process' %>

If this represents your situation (especially if all your tests run quickly enough that you’re confident about deploying to production), you don’t really need a good Continuous Delivery (referred to as CD) solution and you can stop reading this post right here.

However, for most of us, the path from commit to production involves numerous moving parts, (like multiple code and asset repositories, automatic and manual handoffs, unit tests, integration tests, acceptance tests, performance tests, security tests, etc.) and time that it takes to execute all of these elements. When your path to production is not the magical world shown above, you need a way of modeling your workflow so that people can see, understand and talk about it. This is where CD pipelines come in.

In this on-going series, we’ll cover aspects of CD pipelines from why they are important to some of the optimal ways to model them.

## What is a Continuous Delivery Pipeline? {#what-is-cd-pipeline}

A deployment pipeline is an integral part of Continuous Delivery. It is a way of modeling your software delivery process so that it provides feedback and visibility to the team delivering new features.

<NAME>, co-author of the book [Continuous Delivery](https://www.amazon.com/dp/0321601912?tag=contindelive-20), in his [blog](https://continuousdelivery.com/) says,

>*Deployment pipelines tie together configuration management, continuous integration and test and deployment automation in a holistic, powerful way that works to improve software quality, increase stability, and reduce the time and cost required to make incremental changes to software, whatever domain you’re operating in.*

CD pipelines are incredibly useful in telling you as quickly as possible whether a change is good enough to be taken to production.

## Why do you need a CD pipeline? {#why-do-you-need-cd-pipeline}

Boiled down to its essence a CD pipeline is a series of feedback loops.

Quick feedback loops are everywhere, including industries apart from software development. Any situation where you can make a change, see its effect, correct the input to make it go towards a desired outcome (and rinse and repeat) is a great opportunity for feedback loops.

In technology, some of the obvious attempts at feedback loops are [REPLs](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop) (Read-Eval-Print-Loops for languages) and tests. And in the world of build and deployment, a deployment pipeline satisfies the need for quick feedback.

The necessity for a deployment pipeline has been perfectly summed up by [Martin Fowler](https://martinfowler.com/bliki/DeploymentPipeline.html) as this
<commit_msg>Removed draft mode for post<commit_after>---
layout: post
title: "Modeling Deployment Pipelines: The Importance and Principles of Continuous Delivery Pipelines"
type: post
author: <NAME>, Product Manager at GoCD
excerpt: "The path from commit to production involves numerous moving parts, (like multiple code and asset repositories, automatic and manual handoffs, unit tests, integration tests, acceptance tests, performance tests, security tests, etc.) and time that it takes to execute all of these elements. You need a way of modeling your workflow so that people can see, understand and talk about it. This is where CD pipelines come in."
title_tag_of_header: "Importance and Principles of CD Pipelines | GoCD Blog"
meta_description: "You need a way of modeling your workflow so that people can see, understand and talk about it. This is where CD pipelines come in. "
meta_keywords: "GoCD, continuous delivery, goforcd, open source, software, contribute to open source, agile continuous delivery, code contribution, Go"
summary_image: "/assets/images/blog/migrating-snapci-gocd/snapci-migrating-gocd.jpg"
---
In an ideal, magical world, your end-to-end deployment from a commit to production looks like this:

<%= image_tag 'blog/importance-cd-pipelines/magic.jpeg', :alt => 'Magical Deployment', :title => 'Magical Deployment Process' %>

If this represents your situation (especially if all your tests run quickly enough that you’re confident about deploying to production), you don’t really need a good Continuous Delivery (referred to as CD) solution and you can stop reading this post right here.

However, for most of us, the path from commit to production involves numerous moving parts, (like multiple code and asset repositories, automatic and manual handoffs, unit tests, integration tests, acceptance tests, performance tests, security tests, etc.) and time that it takes to execute all of these elements. When your path to production is not the magical world shown above, you need a way of modeling your workflow so that people can see, understand and talk about it. This is where CD pipelines come in.

In this on-going series, we’ll cover aspects of CD pipelines from why they are important to some of the optimal ways to model them.

## What is a Continuous Delivery Pipeline? {#what-is-cd-pipeline}

A deployment pipeline is an integral part of Continuous Delivery. It is a way of modeling your software delivery process so that it provides feedback and visibility to the team delivering new features.

<NAME>, co-author of the book [Continuous Delivery](https://www.amazon.com/dp/0321601912?tag=contindelive-20), in his [blog](https://continuousdelivery.com/) says,

>*Deployment pipelines tie together configuration management, continuous integration and test and deployment automation in a holistic, powerful way that works to improve software quality, increase stability, and reduce the time and cost required to make incremental changes to software, whatever domain you’re operating in.*

CD pipelines are incredibly useful in telling you as quickly as possible whether a change is good enough to be taken to production.

## Why do you need a CD pipeline? {#why-do-you-need-cd-pipeline}

Boiled down to its essence a CD pipeline is a series of feedback loops.

Quick feedback loops are everywhere, including industries apart from software development. Any situation where you can make a change, see its effect, correct the input to make it go towards a desired outcome (and rinse and repeat) is a great opportunity for feedback loops.

In technology, some of the obvious attempts at feedback loops are [REPLs](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop) (Read-Eval-Print-Loops for languages) and tests. And in the world of build and deployment, a deployment pipeline satisfies the need for quick feedback.

The necessity for a deployment pipeline has been perfectly summed up by [<NAME>owler](https://martinfowler.com/bliki/DeploymentPipeline.html) as this

{'fraction_non_alphanumeric': 0.059535696455317026, 'fraction_numerical': 0.0054917623564653024, 'mean_word_length': 5.061270801815431, 'pattern_counts': {'":': 0, '<': 10, '<?xml version=': 0, '>': 16, 'https://': 8, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5399749', 'n_tokens_mistral': 1996, 'n_tokens_neox': 1896, 'n_words': 1115}