The purpose of a deployment pipeline is to make releasing boring. If deployments are stressful, the pipeline is not doing its job regardless of how many stages it has.
Trust is the core property. A test suite with flaky tests trains engineers to re-run until green, which destroys the signal entirely. Fixing or removing flaky tests is more valuable than adding new coverage.
Build once, deploy many. The artefact promoted to production should be byte-identical to the one tested in staging, with configuration injected at deploy time. Rebuilding per environment reintroduces the differences the pipeline exists to eliminate.
Infrastructure as code should cover everything, including the pieces created by hand during an incident. Drift between declared and actual infrastructure is where surprising outages originate.
Deployment strategy should match risk. Rolling deployments suit stateless services; blue-green gives instant rollback at the cost of double capacity; canary releases catch problems with a fraction of traffic. Choose per service rather than mandating one approach.
Database migrations need their own discipline because they are the least reversible part of most deployments. Expand-and-contract — add the new column, backfill, switch reads, then remove the old — allows schema changes without downtime and without a migration that cannot be undone.
Automate the rollback path and test it. Teams that have never practised a rollback discover during an incident that it does not work.
Measure the four metrics that correlate with delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore. They point at where the pipeline actually hurts, rather than where it feels slow.