Most teams treat the pipeline as plumbing. It is the thing that decides whether a bad change ever reaches a customer.
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.
reuse everywhere
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.
then watch
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 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.
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.
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.
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.
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.
Drop your details and we'll send CI/CD Pipeline Blueprint: The Reference Design You Can Copy Stage by Stage straight to your inbox - no spam, unsubscribe anytime.
Talk through how this applies to your roadmap with our engineering leads - a working session, not a sales pitch.
Download White Paper