Deployment Pipeline

A deployment pipeline is an automated sequence of stages that code passes through from commit to production, including build, test, review, and deploy steps.

Definition

A deployment pipeline (also called a CI/CD pipeline) defines every automated step your code goes through on its journey from a developer's commit to running in production. A typical pipeline includes: source control trigger (Git push), build (compile, bundle, generate assets), test (unit, integration, linting), review (automated quality gates, security scanning), staging deploy (pre-production environment), approval gate (manual or automated), and production deploy. Each stage catches different classes of errors. A well-designed pipeline lets teams deploy multiple times per day with confidence, knowing that problems will be caught before reaching users.

Stages of a Deployment Pipeline

Commit triggers the pipeline when a developer pushes code. Build compiles the code, installs dependencies, and creates deployable artifacts. Test runs automated tests: unit tests verify individual functions, integration tests verify component interactions, and end-to-end tests simulate real user behavior. Security Scan checks for vulnerabilities in dependencies and code. Staging Deploy deploys to an environment that mirrors production for final validation. Approval may require manual signoff or pass automatically based on policies. Production Deploy rolls out the changes to live users, often using strategies like blue-green or canary deployments to minimize risk.

Pipeline vs Manual Deployment

Without a pipeline, deployment is a manual ritual: developers run commands, SSH into servers, copy files, and restart services. This is slow, error-prone, and relies on undocumented steps. A pipeline makes deployments repeatable, auditable, and fast. The same pipeline runs the same way every time, eliminating human error. Failed builds never reach staging. Failed staging tests never reach production.

What Makes a Good Pipeline

A good pipeline is fast (under 10 minutes for most projects), reliable (rarely fails due to flaky tests), informative (clear failure messages), and gated (each stage must pass before proceeding). It should also produce artifacts (build outputs, test reports, logs) that teams can inspect. Most importantly, it should make developers want to deploy more often, not dread it.

Note

Pipeline design is platform-specific but the concepts are universal. GitHub Actions, GitLab CI, Jenkins, and CircleCI all implement the same pipeline stages with different syntax.

In code

```yaml
# Pipeline stages (conceptual)
stages:
  - build
  - test
  - security
  - staging
  - production

build:
  script: npm run build
test:
  script:
    - npm run test:unit
    - npm run test:integration
security:
  script: npm audit
staging:
  script: deploy staging
  environment: staging
production:
  script: deploy production
  environment: production
  when: manual  # requires approval

## Common questions

Q: How long should a deployment pipeline take?

A: Aim for under 10 minutes for the full pipeline. If tests take longer, run faster unit tests first and move slower end-to-end tests to a separate parallel stage.

Q: Can I have multiple pipelines?

A: Yes. Many teams have separate pipelines for development branches (fast, limited tests) and production merges (full test suite, security scans, manual approval).

Key takeaways:

- A deployment pipeline automates the full journey of code: build, test, stage, deploy.

- Each stage catches errors before they reach users.

- Automated pipelines eliminate the errors and inconsistency of manual deployments.

- A well-designed pipeline makes frequent, confident deployments possible.