Deployment pipeline

A deployment pipeline is a sequence of automated stages that every code change must pass before reaching production.² Each stage provides fast feedback: if a build fails, the developer is notified immediately; if tests pass, the change proceeds to the next stage. The pipeline ensures that the software is always in a deployable state, eliminating the need for a separate, manual release phase. This practice is central to continuous delivery, where every successful pipeline run can be deployed to production with a single click. The concept was popularized by Jez Humble and David Farley in their 2010 book Continuous Delivery.¹ It replaces the old, ad-hoc manual release process with a repeatable, auditable, and automated workflow.

Typical deployment pipeline stages include commit, build, unit test, integration test, acceptance test, and deployment.³ The pipeline begins when a developer pushes code to a shared version control repository. An automated build compiles the code and produces artifacts (e.g., binaries, container images). These artifacts are then run through a series of test suites, from fast unit tests to slower integration and end-to-end tests. If all tests pass, the artifact is staged and eventually deployed to production. Modern pipelines are often defined as code ("pipeline as code") using tools like Jenkins, GitLab CI/CD, or GitHub Actions, allowing the pipeline itself to be version-controlled and reviewed.⁴ Some pipelines also include security scanning, performance testing, and compliance checks as additional stages.

Key best practices for deployment pipelines include automating everything, keeping feedback fast, and making the pipeline reproducible.⁵ Every stage should be automatic and idempotent; manual approvals should be rare and only for business-critical decisions. The pipeline should run in a production-like environment to catch environment-specific issues early. Teams should monitor pipeline metrics—such as cycle time, failure rate, and time to recover—to continuously improve. Blue-green deployment and canary release patterns are often built into the pipeline to reduce risk during production deployment.⁶ It is also important to treat the pipeline as a first-class product: maintain it, refactor it, and document it. Tools like Jenkins, GitLab, CircleCI, and Spinnaker provide scaffolding for implementing pipelines, but the principles remain tool-agnostic.

Though deployment pipelines are most commonly associated with web applications, they are also used for firmware, databases, and infrastructure-as-code. An edge case is the "pipeline as bottleneck" anti-pattern, where the pipeline itself becomes slow and brittle, defeating its purpose. The first deployment pipeline was arguably the continuous integration build system used by the Chrysler Comprehensive Compensation system in the late 1990s, predating the term.⁷ The concept of rollback is not always built into pipelines; many teams treat a failed deployment as a forward fix rather than a revert. Some organizations use pipelines for data science models, applying the same automated testing and deployment processes to machine learning workflows. Notably, the term "deployment pipeline" was formally defined by Humble and Farley, but similar ideas existed under names like "build pipeline" or "release pipeline" in earlier literature.

Continuous Integration

Practice of merging code changes frequently and automatically testing each merge.

Continuous Delivery

Practice of automatically deploying every change that passes the deployment pipeline to production.

Pipeline as Code

Defining the deployment pipeline configuration in a version-controlled file, enabling review and reproducibility.

Artifact

A build output, such as a compiled binary, container image, or package, that is deployed through the pipeline.

Rollback

Reverting a deployment to a previous version, often performed when a new release fails.