Most teams treat the pipeline as plumbing. It is the thing that decides whether a bad change ever reaches a customer.
The point of a pipeline is not speed. It is to make the safe path the only path, with speed as the side effect.
The common pattern: a release meeting, a manual approval, and a person reading a diff at 6pm on a Friday deciding if it ships.
The approach that works: every check runs automatically, every gate either passes or stops the change, and a green pipeline ships on demand with zero approvals.
Compile the code and build the container image one time, from a clean checkout with pinned dependencies.
Run SAST, SCA, and a secrets scan in parallel before any artifact is built and pushed.
Never send a new version to all production traffic at once. Use a canary, blue-green, or feature flag to expose it to a small slice first.
A change starts at source and only advances when the stage before it passed: source and commit, build, unit tests, integration tests, security scans, artifact and SBOM, deploy to staging, automated checks, progressive delivery, observability, and rollback. Each stage gets one paragraph on what runs and why it sits where it does.
The page to pin above your pipeline config. Every stage gets one gate that must pass, real tool examples, and one defined thing that happens when it fails. Block the merge, fail the build, route to the author, auto-revert the manifest, auto-rollback to last good. No gate means no stage.
Why Git is the only source of truth, how a reconciliation controller closes drift automatically, and why rollback becomes a git revert instead of a recovery operation. Plus a side-by-side of canary, blue-green, and rolling releases so you can pick the right strategy per service.
Deployment frequency, lead time for changes, change failure rate, and failed deployment recovery. What each one measures, what good looks like, and why you track them as a set. Pushing one up while another slips is not a win.
A change should go from a developer's commit to a slice of production traffic without anyone deciding it is safe, because the pipeline already decided.
A complete reference pipeline: all eleven stages from commit to production, a gate and fail-action table with real tool examples, the GitOps model, three progressive delivery strategies, the four DORA metrics, and a maturity checklist you can run your current pipeline against.
The DORA metrics are four measures from Google Cloud's DevOps Research and Assessment program: deployment frequency, lead time for changes, change failure rate, and failed deployment recovery. Two measure speed, two measure stability. A healthy pipeline moves all four the right way at once, which proves speed and safety are not a trade-off.
DevOps leads, platform engineers, and engineering managers who want a pipeline that ships safely without a release meeting. It is a working design, not a survey, so it is most useful to anyone about to build or rebuild a delivery pipeline.
No. The blueprint names tool examples at each stage, like Argo CD, Trivy, Cosign, and Argo Rollouts, but the design is the point. Copy the stages and swap in your own stack. The gates and fail actions hold whatever you build on.
You need the option. When every automated gate is green and policy allows it, a change should reach production with no manual sign-off. The pipeline already verified it. Manual approval is for the exceptions, not the default.
