The measure of a delivery pipeline is not how clever it is. It is how long a one-line fix takes to reach production, and how confident the person merging it is. Everything below serves those two numbers.
The shape
On every pull request: install from a lockfile, type-check, lint, unit tests, build, and the critical end-to-end set. On merge to the main branch: deploy to staging automatically, then production behind whatever approval your governance requires.
One artefact, promoted
The container or bundle tested on staging is the exact one that goes to production. Nothing is rebuilt per environment — configuration is injected at run time. Rebuilding is how a green staging turns into a red production for reasons nobody can reconstruct.
Keeping it fast
Dependency and build caching, jobs parallelised, and the slow suites moved off the pull-request path onto a schedule. If a pipeline takes forty minutes, people batch changes to avoid it, and large batches are exactly what makes a deploy risky.
Database changes
Migrations run as their own step with an explicit order relative to the deploy, and expand-then-contract for anything destructive. This is the part of a pipeline that has no undo, so it gets the most care — see PostgreSQL.
Rollback and after
The previous release is one action away and someone has performed that action during working hours, deliberately, at least once. Deploys are logged with the change they carried, so an incident starts from a list rather than a guess.
Secrets and supply chain
Credentials come from a secrets manager with least privilege, dependencies are pinned, and known vulnerabilities are surfaced on every run rather than discovered in an annual review.
Deploys to AWS, Google Cloud and Kubernetes.