Delivery vs Deployment

Two meanings of CD: continuous delivery (release by button) and continuous deployment (straight to prod, automatically). How they differ, what they have in common, and what a team needs to roll out without a button.

One abbreviation, two meanings

CD has two expansions, and interviewers like to ask the difference:

• Continuous Delivery;
• Continuous Deployment.

The difference comes down to exactly one thing: who triggers the rollout to prod, a person or automation.

Martin Fowler defines Continuous Delivery this way: software is built so that it can be released to production at any moment. His Continuous Deployment means every change goes through the pipeline and lands in prod by itself, so there are many rollouts a day.

The shared part: everything before prod

Both Delivery and Deployment sit on top of CI and do the same thing before production:

commit -> CI (build + tests) -> package the artifact
       -> deploy to staging -> acceptance tests
       -> [ready for production]

At this point you have a verified artifact that can be rolled out at any moment. From here the paths split.

The artifact is built once, then promoted across environments: the same file or image that passed staging goes to prod. Rebuilding right before prod gives you a different build. Nobody tested it: different dependency or base image versions might have been pulled in. In GitLab CI the finished build is passed to the next job through artifacts, or the image is pushed to a registry under an exact tag.

Continuous Delivery: a person decides the release

The artifact is ready and tested, but it ships to prod when a person presses the button. Everything is automated except that final decision to roll out.

When teams do this:

• the release is tied to a business event (marketing, a schedule, a window);
• a manual approval is required (a release manager, someone accountable, regulation);
• prod is critical, and the team wants a deliberate moment of release.

Technically the rollout could happen any second, but a person triggers it.

In GitLab CI the button looks like a job with when: manual:

deploy_production:
  stage: production
  script: ./deploy.sh production
  environment:
    name: production
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

This job shows up in the pipeline and waits for someone with permission to press run. A button isn't the only way to do it. If prod is deployed by a tag pipeline (rules: - if: $CI_COMMIT_TAG), and a release manager creates the tag when they decide to ship, that's still Delivery: a person makes the decision.

Continuous Deployment: no button

Same thing, but the last step is automatic too. A change passes every check and lands in prod by itself, with no manual approval.

When teams do this:

• the team is mature and trusts its tests;
• changes are small and frequent;
• there's a fast rollback and good monitoring: if something's wrong, it gets caught and rolled back within minutes.

No person is involved in the rollout. Merge the MR, and a few minutes later it's already in prod.

Mnemonic

Delivery: we can roll out at any moment (with a button). Deployment: it rolls out by itself, with no button.

Continuous Deployment = Continuous Delivery without the last manual step. That's why Deployment is "stronger": it needs Delivery as a foundation, plus enough trust in the automation.

What this takes

To roll out automatically (or often, by button) safely, a team needs safety nets:

• fast rollback, to bring back the previous version within minutes. That means keeping past artifacts around instead of rebuilding them. In GitLab, an environment has a Rollback environment button: it reruns the deploy job from the last successful deployment;
• monitoring and alerts, to catch degradation right away;
• safe rollout strategies: blue-green (two environments, switch the traffic), canary (roll out to 5% of users, watch, then everyone), feature flags (the code is there, just switched off).

Without these safety nets, Continuous Deployment turns into "automatically breaking prod." That's why many teams deliberately stay on Delivery.

Common mistakes

• Treating any when: manual in a config as a sign of Delivery. If only the rollback is triggered manually and the rollout itself happens on its own, that's Deployment.
• Treating canary as a manual step. Canary only shrinks the blast radius: if the check and the move to 100% are automatic, it's Deployment.
• Rebuilding the artifact right before prod "just in case." That sends a build nobody tested to prod.
• Thinking Delivery means "we roll out rarely." The button can be pressed every half hour: what matters is that the artifact is always ready and a person decides.

What to remember

CD means either Delivery or Deployment. The difference is who triggers the rollout to prod.

Delivery: the artifact is always ready, a person triggers the release to prod.

Deployment: it passed the checks, so it lands in prod by itself, with no manual step.

Deployment = Delivery without the last button, plus trust in tests, rollback and monitoring.

The artifact is built once and promoted across environments without rebuilding.

Safe rollout rests on rollback, monitoring, and the blue-green and canary strategies.

What you'll need for the tasks

• Docker and bash: in lab 1 two environments (staging and prod) run as nginx:1.27.3-alpine containers, and the pipeline runs in a clean alpine:3.20.3 container, the way a CI server would.
• Reading pipeline output: lines like === job: ... === and the build number in build=.
• Basic shell: cp, rm, set -e from the previous lesson.
• Lab 2 only needs a text editor: reading .gitlab-ci.yml and finding rules, when: manual, environment in it.

The next lesson covers pipeline anatomy: stages, jobs, runners, artifacts, secrets.