CI/CD pipelines

This page draws an exact line between continuous integration, continuous delivery, and continuous deployment — the single most misused set of terms in the field — then walks the stages a real pipeline runs on every commit, why the pipeline definition itself lives in version control next to the code it builds, and why stage order is a deliberate cost decision, not an arbitrary list. Read it once and you'll be able to say precisely which of the three C's your own team's pipeline actually implements.

The three C's, precisely

Continuous Integration (CI) means developers merge small changes into a shared trunk frequently — multiple times a day, not once a week off a long-lived branch — and every merge automatically triggers a build and a test run. The practice traces back to Kent Beck's Extreme Programming and was named and popularized by Martin Fowler in the early 2000s. CI's entire promise is narrow: it tells you, within minutes, whether the trunk still builds and still passes its tests. It says nothing about releasing anything to anyone. Frequent merging only works if branches stay short-lived, which is why CI and trunk-based branching strategy are really one practice wearing two names.

Continuous Delivery (CD) extends CI one step further: every change that passes the pipeline produces a release candidate that is automatically verified and proven deployable to production at any time. The pipeline itself builds the confidence; a human still decides when to actually release — often a single click in a deployment tool, but a deliberate, gated decision every time. Jez Humble and David Farley formalized this in their 2010 book Continuous Delivery, and its core claim is strict: if your main branch isn't always in a releasable state, you don't have continuous delivery yet, no matter how much automation you've bolted on.

Continuous Deployment removes that last human gate. Every change that passes every stage of the pipeline ships to production automatically, with no approval step in between. The only thing standing between a merged commit and a production user is the pipeline's own judgment. This is the rule worth memorizing: all continuous deployment is continuous delivery, but not all continuous delivery is continuous deployment. Delivery is the necessary foundation (always releasable); deployment is delivery with the release button wired to the pipeline instead of to a person.

Anatomy of a pipeline: from commit to production

A mature pipeline is a fixed sequence of stages, each one a gate the change must clear before the next stage even starts. A common ordering looks like this, and the order is not incidental — it runs cheapest and fastest checks first:

• Lint — static analysis for style and obvious errors, seconds to run, catches typos and syntax problems before anything else bothers to look at the code.
• Unit test — fast, isolated tests of individual functions and classes, typically finishing in one to a few minutes even for a large suite.
• Build — compile the code or assemble the application into a runnable form, such as a container image, covered in more depth in build and artifact management.
• Integration test — exercise the built artifact against real or realistic dependencies (a database, another service) to catch problems unit tests can't see in isolation.
• Security / dependency scan — static application security testing (SAST) on the code and a software-composition-analysis scan (tools like Trivy, Snyk, or Grype) on the dependency tree, checking for known CVEs before the artifact goes anywhere.
• Package — tag and publish the verified artifact (a container image, a Helm chart, a binary) to a registry, immutable and traceable back to the exact commit that produced it.
• Deploy to staging — roll the packaged artifact out to an environment that mirrors production as closely as the budget allows.
• Smoke test — a short, shallow check against the running staging deployment (does the health endpoint return 200, can a user log in) — not a full regression suite, just proof the deploy itself worked.
• Deploy to prod — the same artifact, unchanged since staging, rolled out to production using whichever deployment strategy the team has chosen — rolling, blue-green, or canary.

Notice the same artifact moves through staging and production unmodified — nothing gets rebuilt between environments. Rebuilding at each stage means you're no longer testing the thing you're about to ship; you're testing a cousin of it.

# pipeline.yml — a generic pipeline definition, versioned in the app's own repo
stages:
  - lint
  - test
  - build
  - scan
  - deploy-staging
  - deploy-prod

lint:
  stage: lint
  script: eslint . --max-warnings 0
  timeout: 2m

test:
  stage: test
  script: npm test -- --coverage
  timeout: 8m
  needs: [lint]

build:
  stage: build
  script: docker build -t registry.internal/app:$CI_COMMIT_SHA .
  artifacts: [registry.internal/app:$CI_COMMIT_SHA]
  needs: [test]

scan:
  stage: scan
  script: trivy image registry.internal/app:$CI_COMMIT_SHA --exit-code 1 --severity HIGH,CRITICAL
  needs: [build]

deploy-staging:
  stage: deploy-staging
  script: kubectl apply -f k8s/staging --image=registry.internal/app:$CI_COMMIT_SHA
  environment: staging
  needs: [scan]

smoke-test:
  stage: deploy-staging
  script: curl -sf https://staging.internal/healthz
  needs: [deploy-staging]

deploy-prod:
  stage: deploy-prod
  script: kubectl apply -f k8s/prod --image=registry.internal/app:$CI_COMMIT_SHA
  environment: production
  when: manual        # this one line is the entire continuous-delivery vs. continuous-deployment boundary
  needs: [smoke-test]

Pipeline-as-code

Pipeline-as-code means the pipeline definition above is a plain text file — YAML, a Groovy Jenkinsfile, a JSON workflow — checked into the same repository as the application it builds, versioned, diffed, and reviewed exactly like the code it protects. Real formats you'll meet: GitHub Actions reads .github/workflows/*.yml, GitLab CI reads .gitlab-ci.yml at the repo root, Jenkins reads a Jenkinsfile written in its Groovy pipeline DSL, and Azure Pipelines reads azure-pipelines.yml. Before this idiom became standard, pipelines were configured by hand through a CI server's web UI — a setup with no history, no code review, and no way to know what changed between last Tuesday's green build and today's red one.

Pipeline-as-code fixes that by treating the pipeline the same way you treat infrastructure in infrastructure as code: a pull request changes the pipeline, a reviewer reads the diff, and git blame tells you exactly who added that flaky test-retry flag and when. It also means the pipeline can branch with the code — a feature branch can carry its own temporary pipeline tweak without touching what every other branch runs, and reverting a bad pipeline change is a git revert, not an email to whoever has admin on the CI server.

The fast-feedback principle

Stage order in the pipeline above isn't alphabetical or arbitrary — it's sorted by a ratio of cost to signal. Lint takes seconds and catches a class of mistake that would otherwise waste minutes of test time; a security scan takes longer and runs after the build exists, because it needs an artifact to scan. The underlying rule is fail fast, fail loud, fail early: put the cheapest, quickest checks first so a broken change gets rejected before the pipeline spends ten minutes building and deploying something that was never going to pass anyway. A defect caught by a linter in a code editor costs a keystroke to fix; the same defect caught after a production deploy costs an incident, a rollback, and someone's evening.

"Fail loud" is the other half: a failed stage must stop the pipeline outright and notify the owner immediately — a red build in a dashboard nobody watches, or a failure silently skipped so the pipeline "goes green anyway," defeats the entire point. There's no such thing as a soft failure in a pipeline gate; a stage either passes and the change proceeds, or it fails and the change stops, full stop, with the person who broke it told right away rather than discovered days later in an incident.

Where the human gate actually sits

In practice, the boundary between delivery and deployment is one mechanism, not a philosophy. GitLab CI's when: manual on a job (as in the YAML above), GitHub Actions' "required reviewers" on a protected environment, a Jenkins input step, and Argo CD's manual-vs-automated sync policy are all the same idea implemented four different ways: the pipeline pauses at the production-deploy stage and waits for a person, or it doesn't. Removing that one gate — nothing else — is what turns a continuous-delivery pipeline into a continuous-deployment one.

Many teams that deploy continuously still control what users actually see using feature flags (tools like LaunchDarkly or the open-source Unleash), decoupling "deployed" from "released": the new code goes to production automatically on every merge, but stays dark behind a flag until someone flips it on for 1% of traffic, then 100%. That's how deployment frequency can hit multiple times a day — the top-quartile mark tracked by the DORA metrics covered in measuring success — without every merge being an uncontrolled surprise for every user at once.