Delivery Pipelines

Definition

A delivery pipeline runs the sequence of checks and steps that take a change from commit to running in production: build, test, scan, package, deploy, verify.

The two properties that decide everything

Speed. Beyond about ten minutes for the commit stage, behaviour changes: people batch changes, stop running it locally, and eventually merge with it red. Pipeline duration is therefore not an efficiency concern — it determines whether the pipeline influences behaviour at all.

Trustworthiness. A flaky pipeline trains the team to re-run rather than investigate, after which its signal is worthless and a genuine failure is dismissed as flakiness.

Everything else is secondary to these two.

The staging that works

• Commit stage — build, unit tests, static analysis, dependency scan. Minutes. Blocks everything.
• Acceptance stage — integration and contract tests against real dependencies. Longer, still blocking.
• Deployment — to production, gated by automated verification rather than by a human.
• Post-deployment — canary analysis, smoke tests, automatic rollback on a defined signal.

Run in parallel where possible, and fail fast: the cheapest checks first, so an obvious error is reported in seconds rather than after a twenty-minute suite.

What belongs in the pipeline and what does not

Belongs: anything mechanically checkable — style, formatting, security scanning, dependency vulnerabilities, licence compliance, test coverage thresholds, infrastructure policy.

Does not: human judgement about design, and approval gates that add latency without adding information. An approver who cannot meaningfully assess the change is contributing delay only.

The properties that make it safe rather than merely fast

• Automated rollback, so a bad deployment costs minutes. This is what makes frequent deployment safe rather than reckless, and it should be built before deployment frequency is increased.
• Expand-and-contract schema migrations, or the database blocks the pipeline.
• The same artefact promoted through environments, never rebuilt per environment.
• Deployment decoupled from release via feature flags, so nothing waits for a feature to be complete.

Failure scenarios

• A slow pipeline, so people batch changes and the batch size problem returns.
• A flaky pipeline, so the signal is ignored.
• Manual gates adding days and no information.
• Different artefacts per environment, so what was tested is not what ships.
• No rollback, so every deployment is a commitment and frequency is rationally reduced.

Interview question

"Your pipeline takes 45 minutes and fails randomly twice a week. Which do you fix first and why?"