“Deployment Pipeline” – Is this it?

The term “Deployment Pipeline” is often used to imply different stages/environments your release candidate has to be deployed to before it can be released (go in “Production”).

When you hear it, you probably think of this


A heavy viscous liquid running through a long pipeline such that every single drop has to pass through every single inch of the pipeline sequentially.

However, Humble and Farley had a very different idea when they coined the term and it looked something like this:


Yes. It is a processor.

They borrowed the idea from the world of hardware where a sequential set of instructions is broken down in parallel threads of execution such that in the worst case there won’t be any time loss over sequential execution. In the best case though, instructions could be parallelized and speed up the execution.

How do they do it? Processors open parallel threads all the time but only when they are confident that they have enough data to predict the outcome of another thread. For example thread 1 is executing. It is the only thread. At some point the processor can predict that the outcome of thread 1 is going to be “X”. Processor takes “X” and hands it to thread 2. thread 2 starts execution.

When Thread 1 completes execution it verifies the actual result. If the result indeed was “X”, processor continues with thread 2. It just managed to parallelize the execution of otherwise serial instruction set.

If however outcome of thread 1 was “Y”, processor simply dumps thread 2 and continues with sequential execution.

Nothing was gained by opening thread 2. But even more importantly, nothing was lost. So there’s no downside and the upside is huge.

Brilliant! isn’t it?

“Deployment Pipeline” works exactly the same way. The commit stage in deployment pipeline is automated to run very quickly. We can now “guess” that all subsequent testing and verification will pass. With that assumption we can open a new thread by picking new items from the backlog to work upon. If the tests succeed, we have a new set of features coming down the pipe – parallel execution. If however, tests fail, no harm done. we simply send the errant code back to developers.

At the end we have achieved parallel execution upstream by being optimistic about the outcome of the activities downstream. 

When you talk about Deployment Pipeline, think of it as an enabler to parallel execution to achieve maximum efficiency of all resources across dev, test and release. Then, and only then, you have a true  Deployment Pipeline as envisioned in the Continuous Delivery paradigm.

Leave a Reply

Your email address will not be published. Required fields are marked *