CD pipeline with gates

A CD pipeline with gates is a deployment pipeline that has explicit checkpoints between stages.

·Merge queue is implemented (GitHub merge queue, Mergify, or equivalent)
·Auto-rebase is enabled for PRs targeting main branch
·CD pipeline includes at least one gate (tests pass, security scan, approval)

·Merge conflicts are detected and flagged before review is requested
·Deploy frequency is at least daily

Evidence

·Merge queue configuration in repository settings or CI
·Auto-rebase configuration (branch protection rules, bot configuration)
·CD pipeline definition showing gate conditions

What It Is

A CD pipeline with gates is a deployment pipeline that has explicit checkpoints between stages. Code doesn't flow from CI to staging to production continuously - it must pass defined criteria at each stage before proceeding. Gates can be automated (CI health checks, smoke tests, error rate thresholds) or manual (approval from a release manager before production deploy). The defining characteristic of L2 CD is that the gates exist and are enforced by the pipeline, not just by convention.

This is a significant upgrade from simple CD (push to main, auto-deploy). The structure is: merge to main → build → deploy to staging → automated smoke tests → optional manual gate → deploy to production → post-deploy health check. Each transition is conditional. A failure at staging stops the pipeline and prevents production deployment. A failed post-deploy health check triggers an alert before the problem reaches users en masse.

The "gate" concept is important because it decouples pipeline stages from human availability. Without gates, someone has to watch every deploy and make judgment calls. With gates, the pipeline makes the obvious decisions automatically (smoke tests pass → promote to prod) and escalates only the ambiguous ones (smoke tests pass but latency increased 15% → alert for human decision). This makes CD sustainable at higher deploy frequency.

At L2, gates are typically: (1) CI must pass on the merged commit, (2) staging smoke tests must pass, (3) production deploy must pass a post-deploy health check. Manual approval gates for production are common at this level and are not a failure - they're appropriate where the risk profile warrants human judgment before each production change.

Why It Matters

Catches problems before they reach production - a gate at staging that requires smoke tests to pass prevents broken code from reaching users; at high deploy frequency this is not a nice-to-have but a requirement
Enables delegation of deploy decisions - with explicit gates, junior team members can execute deploys safely; the gate enforces the criteria so the deployer doesn't need expert judgment on "is this safe to deploy?"
Increases deploy confidence and frequency - teams with fragile deploy processes deploy infrequently out of fear; structured gates with automated validation create confidence that each deploy has passed a defined bar, enabling higher frequency
Creates audit trail for compliance - gates with explicit pass/fail logging create a record of what was tested before each deployment, which is valuable for compliance and post-incident analysis
Foundation for full automation - moving from manual gates to automated gates (L4) requires understanding what decisions the manual gates are making; structured CD pipelines at L2 make those decisions explicit and analyzable

Getting Started

Map your current deploy stages - identify the environments code passes through from merge to production. Typical: main branch → staging → production. Each transition is a gate candidate. Write down what currently happens at each transition (nothing? manual approval? health check?).
Implement a staging smoke test suite - create a set of 5-10 automated tests that exercise your most critical user journeys (login, key feature, payment flow, etc.). These run after staging deploy. If any fail, the pipeline stops. The smoke tests don't need to be comprehensive - they need to be fast (under 5 minutes) and reliably catch regressions.
Add a post-deploy health check - after each production deploy, the pipeline should automatically check: application health endpoint returns 200, error rate hasn't spiked, p95 latency is within normal range. Configure this as a 5-minute observation window post-deploy with automatic alerting if thresholds are exceeded.
Implement the pipeline in your CI tool - GitHub Actions supports multi-environment deployment workflows with environment configurations that can require approvals. ArgoCD supports automated promotion between environments with configurable gates. Choose the tool that fits your existing stack.
Start with one manual gate - place a manual approval gate before production deploy. This is not the end state, but it builds team confidence in the pipeline: developers learn to trust that staging validation is real, and operations learns to trust that CI-gated code is safe. After 60 days of smooth operation, evaluate whether the manual gate can be replaced with automated criteria.
Define rollback criteria - for each gate, define what triggers rollback versus retry. Post-deploy error rate > 2x baseline = automatic rollback. Post-deploy error rate = 1.5x baseline = alert and wait. Making rollback criteria explicit removes judgment calls during incidents.

Tip

The most common reason gated pipelines get bypassed is that they're too slow. If staging deploy + smoke tests takes 30 minutes, developers will find workarounds. Target under 15 minutes from merge to "ready for production gate." Anything longer creates pressure to skip the gate.

6 steps to get from here to the next level

Common Pitfalls

Gates that always pass. A smoke test that never fails is not providing coverage - it's providing false confidence. After implementing your smoke test suite, verify that it would have caught the last three production incidents. If it wouldn't have, add tests that would have. Gates only add value if they actually block bad deploys.

Manual gates that become rubber stamps. A manual approval gate where the approver clicks "approve" without reviewing anything is worse than no gate - it creates false confidence and diffuses accountability. If you have manual gates, define what the approver is expected to check. If they can't explain what they're approving, either add automation to make the decision deterministic or remove the gate and replace it with monitoring.

No rollback automation. A pipeline with gates but no automated rollback forces manual intervention when a post-deploy check fails. During an incident, manual rollback is slow and error-prone. The gate system should include: "if post-deploy health check fails within N minutes, automatically rollback to previous version." This is the safety net that makes automated gates trustworthy.

Flaky smoke tests that block deploys. A smoke test that fails 10% of the time for non-deployment reasons creates friction that causes teams to bypass the gate. Every smoke test failure should be investigated. Flaky smoke tests should be quarantined or fixed before they become gate blockers. A reliable gate is a trusted gate.

Environment drift between staging and production. Gates are only useful if staging reflects production. If staging has a different database, different environment variables, or different infrastructure configuration, a smoke test passing in staging tells you little about production. Environment parity is a prerequisite for meaningful staging gates.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's team has a CD pipeline that deploys on merge but has no intermediate gates. Production incidents typically go undetected for 5-15 minutes after deploy (when users start reporting errors) rather than being caught by automated checks. The last three incidents could have been caught by a post-deploy error rate check within 2 minutes. Bob wants to improve the safety of deploys without slowing them down significantly.

What Bob should do: Bob should invest in post-deploy observation windows as the first gate. This doesn't slow deploys - it runs in parallel with production receiving traffic. The implementation is: after deploy, monitor error rate and latency for 5 minutes. If either exceeds a threshold, alert the on-call and pause subsequent deploys. This catches the majority of bad deploys within minutes without adding gate latency. Bob should also commission a staging smoke test suite for the five most-critical user journeys - a one-sprint investment that prevents the most common categories of production incident. Together, these make the CD pipeline defensible before moving toward automation.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah has observed that the team's "mean time to detect" production issues is 12 minutes after deploy - users report problems before the team knows there's a problem. This creates reactive, high-stress incident response. She wants to reduce detection time to under 2 minutes through automated post-deploy checks, but the infrastructure team is concerned about alerting fatigue.

What Sarah should do: Sarah should propose a pilot: instrument the post-deploy health check for one service with clear alert criteria (error rate 2x baseline, p99 latency 50% above baseline). Run it for 30 days and measure: how often does it fire? How many of those are real incidents? How quickly is the on-call notified? If the alert quality is high (few false positives, catches real incidents), expand to all services. The concern about alerting fatigue is valid - the fix is well-calibrated thresholds, not no thresholds. Sarah should own the threshold calibration process, since it's ultimately a developer experience problem (noisy alerts are worse than no alerts) that falls in her domain.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has already implemented a sophisticated CD pipeline for his team's main service using ArgoCD with automated staging promotion and manual production approval. He wants to move the production gate from manual to automated but can't get sign-off without a defined criteria set.

What Victor should do: Victor should analyze the last 20 manual production approvals: in how many cases did the approver actually look at the staging metrics before approving? What specific data did they use? What would have to be true for them to reject an approval? This analysis typically reveals that manual approvers are rubber-stamping when certain automated criteria are met. Victor should translate those criteria into an automated gate: if staging smoke tests pass, error rate delta < 5%, and latency delta < 10%, auto-promote to production. Present this to stakeholders as "we're automating the easy approvals; anything outside these thresholds still requires human judgment." This framing preserves human oversight while automating the mechanical majority.

What Victor should do - role-specific action plan