13 · CD: build, push & deploy
CI proves a change is good; Continuous Delivery ships it. On merge to main, a workflow builds the Docker image, pushes it to a registry, and deploys — with secrets kept out of the code and an optional manual approval gate before production.
Continuous Delivery (CD) automates the path from a green merge to a running service: on merge to `main`, a workflow BUILDS the Docker image, logs into and PUSHES it to a registry, and DEPLOYS it. Credentials come from GitHub SECRETS (never the code), and a protected ENVIRONMENT can require a manual approval before the production deploy — so CI verifies the change and CD ships it, safely and repeatably.
Without this:
Without CD, every release is a manual checklist someone runs by hand — build the image, log in, push, SSH in, restart the service — which is slow, easy to do inconsistently, and a frequent source of 'the deploy I did at 2am' outages.
CI (lesson 12) answers "is this change good?" — it runs the tests and lint on every PR. Continuous Delivery (CD) answers the next question: "now that it's good and merged, get it running." CD automates the release path so that shipping is no longer a careful manual ritual but a button — or an automatic consequence of merging to main.
The canonical CD pipeline for a containerized model service has four moves, usually triggered on: push: branches: [main] (i.e. when a PR merges):
1. Build the image. docker build packages the FastAPI service + model into an image (lessons 5 & 7) — built fresh on the CI runner from the exact merged code.
2. Log in to the registry. Before you can push, you authenticate to the container registry (Docker Hub, GHCR, AWS ECR). This needs credentials — which brings in secrets.
3. Push the image. docker push uploads the tagged image to the registry, where the deploy target can pull it. Tag it with the git SHA (immutable, traceable) and/or latest.
4. Deploy. Tell the runtime to pull and run the new image — a cloud platform deploy command, a kubectl rollout, an SSH-and-restart. The service is now live on the new version.
Three things make CD safe, not just automatic:
Secrets. Registry passwords, cloud keys, and deploy tokens must NEVER be hard-coded in the workflow YAML (which lives in your repo, visible to anyone with read access). GitHub Secrets store them encrypted; the workflow reads them as ${{ secrets.REGISTRY_PASSWORD }} at run time, and GitHub masks their values in logs. Same principle as the env-driven config from lesson 7 — credentials live outside the code.
Environments. GitHub lets you define protected environments (e.g. production). A job targeting an environment can require an explicit, recorded approval and can scope secrets to just that environment.
Manual approval gates. For production specifically, you often want a human in the loop: the pipeline builds, tests, and pushes automatically, then pauses at a deploy step that waits for a designated reviewer to click "approve". This is the line between Continuous Delivery (automated up to a human-approved release) and Continuous Deployment (fully automatic, no gate) — most ML teams choose delivery-with-a-gate for the production step.
GitHub Actions runs on GitHub's servers, so the deploy workflow below is read-along — but build → login → push → deploy, with secrets and an approval gate, is the shape of essentially every container deploy pipeline.
A `deploy.yml` CD workflow triggered on push to main: build the Docker image, `docker login` with GitHub secrets, push the tagged image, then deploy — targeting a protected `production` environment for an approval gate.
CI/CD pipeline: each stage must pass before the next runs — a failure halts the deploy.
What is the difference between Continuous Integration (CI) and Continuous Delivery (CD)?
- CI verifies a change (tests + lint on every PR); CD ships the verified change — on merge to main it builds the image, pushes it to a registry, and deploys.
- The canonical CD pipeline is build → registry login → push → deploy, triggered `on: push: branches: [main]`, tagging the image with the immutable git SHA.
- Credentials come from GitHub Secrets (never hard-coded), and a protected environment can require a manual approval gate before the production deploy — Continuous Delivery vs Continuous Deployment.
Production model services are released through a CD pipeline: a green merge automatically builds and pushes the container image and deploys it, with secrets and an approval gate — the same automation that lets teams ship models safely many times a week.
If you remove it: Every release would be a manual checklist run by hand — build, log in, push, restart — slow, inconsistent, and a frequent source of late-night deploy outages.