LibraryFirst Way: FlowTools & TechniquesThe Deployment Pipeline

FT-02TOOLFirst Way: Flow

The Deployment Pipeline

The automated path from code commit to production. How to build it, what it must include, and why it is the foundation of fast, reliable delivery.

Sources:DevOps HandbookContinuous Delivery — Humble & Farley

Video Lesson

A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.

01

What is a deployment pipeline?

A deployment pipeline is the automated process that takes every change from version control through build, test, and deployment stages to reach production. It is the embodiment of the principle: every change is a release candidate until proven otherwise.

Jez Humble and David Farley introduced the term in Continuous Delivery (2010). The pipeline replaces manual, error-prone release processes with a repeatable, auditable, automated system.

Source

git push

Build

compile + package

Test

unit + integration

Deploy Staging

automated

Deploy Production

automated / gated

Every commit to main triggers the pipeline. The only way to production is through all stages.

02

The four stages of a pipeline

1

Source control

Every change starts with a commit to version control. The pipeline is triggered automatically. No manual steps, no out-of-band changes.

2

Build and unit test

Compile the code. Run all unit tests. This stage must complete in minutes. If it takes longer, developers stop running it locally.

3

Integration and acceptance

Run integration tests, contract tests, and acceptance tests against a production-like environment. Slower than unit tests but catches different bugs.

4

Deploy

Promote the artifact through staging and into production. The artifact built in stage 2 is the same one deployed — never rebuilt.

03

The pipeline as the only path to production

The most important rule of the deployment pipeline: if it is not in the pipeline, it does not deploy. No SSH deployments. No manual uploads. No emergency hotfixes that bypass the pipeline. Every exception creates risk and erodes trust in the process.

This sounds strict. It is. The strictness is the point. When the pipeline is the only path, every deployment is tested, auditable, and repeatable. When exceptions are allowed, the exceptions become the default in a crisis — exactly when you can least afford them.

Every time you bypass the pipeline, you are trading short-term speed for long-term fragility. Elite teams deploy more frequently than low performers precisely because they never bypass their pipelines.

04

Pipeline metrics

Build time

Under 10 minutes

Developers will not wait for slow builds. If the build takes 30 minutes, developers batch commits and integration problems compound.

Test coverage

70%+ meaningful

Coverage is a proxy, not a goal. 70% meaningful coverage beats 95% coverage of trivial getters. Focus on critical paths.

Deployment frequency

Multiple per day

How often does the pipeline produce a production deployment? Elite teams deploy on demand. Low performers deploy monthly.

Lead time

Under one hour

Time from commit to production deployment. This is what the DORA Lead Time metric measures. The pipeline is the primary lever.

05

The Nexus Corp pipeline

In Mission 03, you built Nexus Corp's first CI pipeline using GitHub Actions. Here is the before and after:

Before M-03

  • Manual deployments from a zip file
  • No automated tests
  • Bugs discovered in production
  • Deploy once per month
  • Lead time: 43 days

After M-03 + M-04

  • GitHub Actions triggers on every push
  • Tests run automatically in CI
  • Bugs caught before staging
  • Deploy on every green build
  • Lead time: 14 days
06

Further reading

Continuous Delivery — Humble & Farley

The definitive book on deployment pipelines. Chapter 5: Anatomy of the Deployment Pipeline.

DevOps Handbook — Part II

The Technical Practices of Flow. Chapters 10-12 cover pipeline design, test automation, and deployment architecture.

Accelerate — Forsgren, Humble, Kim

The DORA research linking deployment pipeline practices to organizational performance.

The Phoenix Project

Parts 2-3: Bill's transformation of the Unicorn deployment process. The pipeline as narrative.