CD pipeline with gates

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.

• 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

1. 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?).
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

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.