CI/CD cheat sheet · Django

1.The pipeline, and the gates in the right order

A pipeline is a fixed sequence that runs on every push: lint, type check, unit tests, integration tests, security scan, build, deploy, migrate, health check, smoke test. **GitHub Actions** and **GitLab CI** both describe it as YAML in your repository — jobs made of steps, running on a fresh machine each time. A **test environment** is what those tests run against: a real PostgreSQL and Redis started for the job, not mocks and not production.

Key features

The order is cheapest-first: lint → types → unit → integration → scan → build
Build once; every later stage acts on the artefact, never on the source again
Each gate names a different class of failure — that is what makes it a pipeline
Test against real PostgreSQL and Redis service containers, not SQLite and not mocks
`makemigrations --check --dry-run` catches the model change with no migration
`check --deploy` must run against the *production* settings module to mean anything

The roadmap's pipeline, with what each stage actually catches

The roadmap's pipeline, with what each stage actually catches
Stage	Typical duration	The failure it exists to catch
lint	seconds	style and obvious errors, before anything costly runs
type check	seconds	a signature that no longer matches its callers
unit tests	a minute or two	logic, with no services involved
integration tests	longer — services start	the parts that only fail against a real database
security scan	seconds to a minute	a known-vulnerable dependency, before the build
build → image	minutes	a build that does not reproduce, or a missing file
deploy → migrate → health → smoke	minutes	everything that only exists in a real environment

GitHub Actions and GitLab CI — the same shape, two vocabularies

GitHub Actions and GitLab CI — the same shape, two vocabularies
Concept	GitHub Actions	GitLab CI
file	`.github/workflows/ci.yml`	`.gitlab-ci.yml`
unit of work	a `job`, made of `steps`	a `job`, made of `script` lines
ordering	`needs:`	`stage:` and `needs:`
services	`services:` on the job	`services:` on the job
reusable step	an `action` (`uses:`)	an `include:` or a template
secrets	`secrets.NAME`, masked in logs	CI/CD variables, masked and protected

One CI job, part by part

jobs: test: runs-on: ubuntu-latest permissions: { contents: read } services: db: { image: postgres:16 } steps: - uses: actions/checkout@v4 - run: python -m pytest -q

jobs:

Jobs run in parallel by default — Independent jobs start together; `needs:` is what imposes order. Splitting lint and tests into separate jobs gives you both results at once instead of stopping at the first.

runs-on: ubuntu-latest

A fresh machine, every run — Nothing survives from the last run unless you cache it deliberately. That is what makes a green pipeline meaningful — and why "works on my machine" cannot happen here.

permissions: { contents: read }

The token this job gets — Narrow it explicitly. A job that only runs tests has no reason to be able to write to the repository, and a compromised dependency inherits exactly these permissions.

services:

Real backing services — A PostgreSQL container started for this job. Django creates and destroys its test database inside it, so constraints, transactions and migrations run against the engine production uses.

actions/checkout@v4

A pinned third-party step — A version, not a moving branch. An action runs arbitrary code in a context that holds your secrets, so what it resolves to should not change between runs without you choosing it.

python -m pytest -q

The step that is just a command — It runs the same thing you run locally. When the pipeline gets clever here — bespoke flags, CI-only paths — a green pipeline stops predicting a green machine.

Command

bash

python manage.py makemigrations --check --dry-run   # fails if a migration is missing

Run the gates cheapest-first — lint, types, unit, integration, security scan — so a two-second failure never waits behind a five-minute one, and build once so everything afterwards acts on the artefact. Both GitHub Actions and GitLab CI are the same shape: YAML in the repository, jobs of steps, a fresh machine each run. Test against a real PostgreSQL service container, because SQLite is green exactly when the schema is wrong. Install from a lock file so a red build means your change. And add the two Django gates a test suite does not give you: `makemigrations --check --dry-run`, and `check --deploy` run against the production settings module.

2.Secrets in the pipeline, and scanning what you depend on

CI needs credentials — a registry login, a deploy key, sometimes a database password — and every one of them is handled by a machine that also runs code from your dependencies. So secrets live in the provider's masked store, are injected per job, and are never printed. **Dependency scanning** is the step that checks your locked dependency tree against known vulnerabilities, and it belongs *before* the build, so a vulnerable package never becomes an image.

Key features

The runner holds credentials *and* runs third-party code — treat it as privileged
Inject secrets per job, and narrow the job's token; a test job needs no deploy key
Masking protects the exact string, not a base64 of it or a fragment in a traceback
A secret in an `ENV` layer or a build argument is permanent and distributable
Scan the lock file, not the manifest — the resolved tree is what ships
Grade the policy: fail on critical runtime findings, or a blanket ignore appears

Which job needs which secret — and which do not

Which job needs which secret — and which do not
Job	Needs	Must not have
lint / type check	nothing	every credential in the store
unit + integration tests	a throwaway CI database password	production database, registry, deploy keys
dependency + secret scan	nothing (or a scanner token)	anything that can deploy
build + push image	registry credentials	production settings and database
deploy	deploy credentials, scoped to one environment	the ability to write to the repository

Four ways a secret escapes a pipeline that "uses the secrets store"

Four ways a secret escapes a pipeline that "uses the secrets store"
Route	How it happens	What stops it
the log	`echo $TOKEN`, `set -x`, a debugging line left in	never print; masking is a backstop, not a control
a traceback	`DEBUG=True` renders settings on error	production settings in CI too; `check --deploy`
an image layer	`ENV SECRET_KEY=…` or `--build-arg`	inject at run time only; `env_file`, never a layer
a fork	a pull request from outside running with secrets	restricted triggers; no secrets on untrusted runs

Where a secret can leave the pipeline

The secrets store is one control, not four. Each of these routes bypasses masking entirely, and three of them leave a copy that outlives the run.

Command

yaml

env:
  REGISTRY_TOKEN: ${{ secrets.REGISTRY_TOKEN }}   # on the push job only

The runner holds credentials and runs third-party code, so scope secrets per job and narrow each job's token — the scan and test jobs need no deploy key at all. Assume masking protects only the exact string: never print a secret, keep `DEBUG` off so a traceback cannot render settings, never write one into an image layer or a build argument, and do not let a fork's pull request run with them. Scan the lock file rather than the manifest, before the build, so a vulnerable package never becomes an image. And grade the policy — fail on critical runtime findings, report development-only ones — because a gate that fails on everything is a gate that gets switched off.

3.Build once, promote, approve — and be able to go back

Build the image **once**, tag it with the commit, and promote that exact artefact through staging and production — never rebuild per environment. **Artifact management** is keeping those images (and their provenance) long enough to redeploy an old one. **Approvals** are a human gate before a protected environment. A **rollback** is redeploying the previous tag, and it only works when the database schema still accepts the old code.

Key features

Build once, tag with the commit SHA, promote that digest — never rebuild per environment
Moving tags like `latest` make "what is running?" and "redeploy yesterday" unanswerable
Retention is a rollback requirement: you cannot redeploy an image you deleted
Approvals belong on protected environments only, and should name the digest
Code rollback is fast; schema rollback usually is not — they are not symmetrical
Every release plan states whether a rollback exists, or that the fix is forward-only

Which schema changes leave you a rollback

Which schema changes leave you a rollback
Migration	Old code still works?	Rollback plan
add a nullable column	yes — it ignores the column	redeploy the old tag; leave the column
add a table or an index	yes	redeploy; the extra object is harmless
add a NOT NULL column with a default	yes, if the default is set	redeploy; new rows still get the default
drop a column the old code reads	no — every query on it errors	no rollback: forward fix, or restore the column first
rename a column	no	expand/contract instead: add, backfill, switch, drop later
narrow a constraint (add UNIQUE)	maybe — old code may write duplicates	drop the constraint before rolling code back

Tagging that answers the questions you will actually ask

Tagging that answers the questions you will actually ask
Tag	Answers	Keep for
`app:8f3c2ad`	exactly which commit is running	as long as it might need redeploying
`app:v1.14.0`	which release this is, for humans	the life of the release series
`app:production`	nothing — it moves	convenience only; never a rollback target
`app:latest`	nothing at all	do not use it in a deployment

One artefact, three environments, and the way back

CI

registry

staging

approver

production

1push app:8f3c2ad (built once)tagged by commit; v1.14.0 points at the same digest
2deploy 8f3c2ad
3smoke tests passthe artefact is now tested, not the source
4production requires approval of digest 8f3c2ad
5approved — deploy the same digestno rebuild: promotion, not reconstruction
6migrate (expand only)additive, so 8f3c2ac still runs against this schema
7health + smoke pass
8if not: redeploy app:8f3c2acpossible only because the previous image still exists and the schema is compatible

Command

bash

docker build -t app:$GIT_SHA . && docker push app:$GIT_SHA
# every later stage deploys that tag; nothing rebuilds

Build once, tag by commit, and promote the digest — a rebuild per environment produces a different artefact and quietly invalidates whatever staging told you. Keep images long enough to redeploy any release you might have to go back to, because a rollback that needs a build is not a rollback. Put approvals on protected environments and record which digest was approved. And keep code and schema rollback separate in your head: redeploying the previous image is fast, but it only works if the migration was expand-shaped. When it is not, say so in the release plan — the deployment is forward-fix-only.