A delivery pipeline is a promise: every change that reaches production has passed through the same sequence of checks. When the pipeline is predictable, teams stop arguing about whether something is ready and start trusting the process.
Most pipelines share a familiar shape. A commit triggers a build, the build produces an artifact, and that artifact moves through testing, scanning, and deployment without being rebuilt along the way.
Build once, promote everywhere
The single most useful rule is to build an artifact exactly once. The image that passed your tests should be the same image that runs in staging and production. Rebuilding at each stage quietly reintroduces the drift the pipeline was meant to remove.
- Tag artifacts with the commit hash, not a moving label.
- Keep environment configuration outside the artifact.
- Promote by reference, never by rebuilding.
A pipeline is only as trustworthy as its slowest manual step.
Make failures cheap
Fast stages should run first. Linting and unit tests fail in seconds, while integration suites and security scans take longer. Ordering stages by cost means most broken changes are rejected before they consume expensive runner time.
Finally, treat the pipeline definition as code. Review it, version it, and test changes to it on a branch. A pipeline that only one person understands is a single point of failure.