Quality Gates in CI/CD
A quality gate is a CI/CD checkpoint that blocks merges unless criteria pass. How gates work, real tool examples, and DORA's evidence on approval boards.
A quality gate in CI/CD is an automated checkpoint that blocks a build, merge, or release unless it meets predefined, measurable conditions — no new issues, coverage above a threshold, a clean security scan, a required approval. DORA's own research found no evidence that adding a formal human approval board on top of that lowers change failure rate; it mainly makes releases slower and larger. Build the gate out of automated checks — SonarQube conditions, branch protection, merge request approval rules — not a committee.
Key takeaways
- A quality gate is a pass/fail checkpoint with measurable conditions, not a person eyeballing a diff — that's what separates it from a generic code review.
- SonarQube's default 'Sonar way' gate checks new code only (no new issues, all Security Hotspots reviewed, ≥80% new-code coverage, ≤3% new-code duplication) — it's 'clean as you code,' not a retroactive rewrite of legacy code.
- GitHub branch protection and GitLab MR approval rules let you build real quality gates natively — required status checks, required reviewers, required conversation resolution — with no separate tool.
- DORA's 2019 research found no evidence that formal external Change Advisory Board review lowers change failure rate; it correlates with slower, larger, riskier releases instead.
- DORA's recommended alternative to CABs is peer review at check-in plus automated detection — continuous testing, CI, and monitoring — which is exactly what a well-built quality gate automates.
A quality gate in CI/CD is an automated checkpoint in a pipeline that blocks a build, merge, or release from moving forward unless it meets a predefined, measurable set of conditions — a passing test suite, a coverage threshold, zero new critical issues, a clean security scan, a required approval. It returns a pass or fail; there’s no judgment call and no waiting on a person to read a checklist. Gates sit at multiple points — on pull requests, before merge, before deploy — and the strongest release-readiness setups chain several rather than relying on one.
Most write-ups on this topic are a shopping list of tools. This one goes deeper: the actual conditions SonarQube, GitHub, and GitLab enforce, and — the part almost nobody cites — DORA’s own research on whether a human approval layer on top of automated gates reduces failed releases.
How do quality gates work?
A quality gate runs as a pipeline step, most often on a pull/merge request or as the last check before deploy. It compares the build or diff against conditions fixed in policy ahead of time, not decided in the moment. If every condition passes, the pipeline proceeds; if one fails, the merge or deployment is blocked until the underlying issue is fixed, not the gate.
The key property is consistency: the same code gets the same verdict regardless of who submitted it or how busy the reviewer queue is. That’s what separates a gate from a generic CI job — it’s explicitly a release-readiness decision point, not just a step that runs and reports.
What are examples of CI/CD quality gates?
Four mechanisms cover most of what teams actually use in production pipelines:
| Gate type | What it enforces | Example conditions |
|---|---|---|
| Static analysis (SonarQube “Sonar way”) | Code quality and security on new code | No new issues; all new Security Hotspots reviewed; new-code coverage ≥ 80.0%; duplication on new code ≤ 3.0% |
| Required status checks (GitHub) | CI jobs must complete before merge | Status must be successful, skipped, or neutral; can require deployment to an environment first |
| Required reviews (GitHub / GitLab) | Human approval before merge | N required approvals; GitLab supports 0–100 per rule; can be scoped to Code Owners |
| Security scanning | No new exploitable vulnerabilities | Build fails on new critical/high findings introduced by the change |
SonarQube’s default gate only checks new code — and that’s the point
SonarQube’s built-in “Sonar way” quality gate has four conditions, verified on SonarQube’s own documentation: no new issues introduced, all new Security Hotspots reviewed, new code test coverage of at least 80.0%, and duplication on new code no higher than 3.0%. For what test coverage actually measures and why the new-code-vs-whole-codebase distinction matters, see what is test coverage.
The detail teams miss: every condition applies to new code only, not the whole codebase. SonarQube calls this “clean as you code” — the gate doesn’t demand you retroactively fix a decade of legacy debt; it only asks that whatever you touch today meets the bar. A ten-year-old monolith with 40% overall coverage can still pass cleanly, as long as new commits carry their own coverage and introduce no new issues. Teams that assume otherwise either over-invest in an unnecessary rewrite, or give up on the gate because the bar looks impossible.
GitHub branch protection as a native quality gate
GitHub’s branch protection lets required status checks block a merge unless they report successful, skipped, or neutral. It also supports required PR reviews, required conversation resolution, required deployments to an environment before merge, and merge queues that re-run checks against the latest target-branch state instead of a stale snapshot.
GitLab merge request approval rules
GitLab’s merge request approval rules define how many approvals an MR needs before it can merge and who’s eligible to give them. Rules integrate with Code Owners, and a project can require anywhere from 0 (optional) up to 100 approvals per rule.
Do change approval boards (CABs) actually reduce failed deployments?
This is where most “quality gates” content stops short, and the evidence points somewhere counterintuitive.
DORA’s 2019 State of DevOps Report tested the assumption that a formal, external change-approval process — a CAB signing off on releases — reduces the rate of failed changes. As DORA documents on its change-approval capability page, it found no evidence for that. Heavyweight external review didn’t ship more reliably; it instead correlated with releasing in larger batches, less frequently — the pattern DORA elsewhere associates with higher, not lower, change failure rates.
The mechanism: a CAB is a queue. Queues create pressure to batch changes to make each review “worth it,” and bigger batches are riskier to ship. A CAB also reviews intent, not behavior, so it can’t catch what automated tests catch: whether the change actually works.
DORA’s recommendation isn’t “skip review” — it’s to replace the external board with peer review at check-in plus automated detection through continuous testing, CI, and monitoring. A required-reviewer rule in GitHub or GitLab is that lightweight peer review, as long as it stays embedded in the pipeline rather than growing into a separate committee with its own schedule. (For the metric definitions themselves, see our guide to DORA metrics for QA teams.) This is the same evidence shift-left testing draws on more broadly — catching problems early and automatically beats a late-stage human gate, whether that gate is a CAB or a slow review queue.
What’s the difference between a quality gate and a code review?
A code review is a human judgment call — is this design sound, is this readable — subjective and only as consistent as the reviewer’s attention that day. A quality gate is an automated, objective pass/fail check against conditions fixed in advance, applied identically every time.
The two aren’t opposites. A required-reviewer rule turns code review into a quality gate: instead of a courtesy someone can skip under deadline pressure, the pipeline enforces it as a merge condition. What matters is the distinction between that kind of embedded, lightweight review — which DORA’s evidence supports — and a separate, heavyweight external approval process, which it does not.
How do you set up a quality gate without a dedicated tool like SonarQube?
You don’t need a separate product to start. Both major Git hosts have enough built in:
- Turn on branch protection (GitHub) or protected branches (GitLab) on your default branch.
- Add required status checks tied to your CI job names — test suite, linter, build — blocked unless each reports successful, skipped, or neutral.
- Require reviewer approval. Set a minimum reviewer count in GitHub, or an MR approval rule in GitLab, scoped to Code Owners for sensitive paths.
- Require conversation resolution so open review comments can’t be silently merged past.
- Add a coverage or duplication check in CI if you don’t run SonarQube — fail below a threshold, scoped to changed files, for the same “new code only” behavior.
- Use a merge queue if you merge frequently, so checks re-run against the latest target-branch state, not a stale snapshot.
- Add a pre-deploy gate on release signals — pass rate and flake rate tell you whether “all checks passed” means the release is actually safe, or just that flaky tests got retried into passing.
That last point is where merge-time and release-time gates diverge — a PR can pass every required check and still ship on a suite built from test cases nobody trusts or maintains. Qualflare turns pass rate, flake rate, and failure trends into a measurable signal a release gate can check against, the same way a test plan’s exit criteria are meant to work — a real threshold, not a vibe. Every gate on this page is static and deterministic — a fixed number decides the outcome. Once that threshold becomes a learned risk score instead of a fixed rule, the gate needs its own governance layer; see AI quality gates: governing an automated release-readiness decision.
Frequently asked questions
What is a quality gate in CI/CD?
A quality gate in CI/CD is an automated checkpoint that blocks a build, merge, or release unless it meets predefined, measurable conditions — a passing test suite, a coverage threshold, zero new critical issues, a required approval. It returns a pass/fail verdict, not a judgment call.
How do quality gates work?
A quality gate runs as a pipeline step, usually on a pull request or before deploy, and checks the code against fixed conditions set in advance. If every condition passes, the pipeline proceeds; if one fails, the merge or deployment is blocked until it’s fixed.
What are examples of CI/CD quality gates?
SonarQube’s default gate (no new issues, reviewed Security Hotspots, coverage and duplication thresholds on new code); GitHub required status checks and required reviews; GitLab MR approval rules; and security-scanning steps that fail the build on new vulnerabilities.
What’s the difference between a quality gate and a code review?
A code review is a subjective human judgment call; a quality gate is an automated, objective pass/fail check against fixed criteria. A required-reviewer rule in GitHub or GitLab is itself a quality gate — it turns review into an enforced condition rather than an optional courtesy.
Do change approval boards (CABs) actually reduce failed deployments?
DORA’s 2019 State of DevOps Report found no evidence that formal, external change-approval review lowers change failure rate — it correlated with slower, larger, riskier releases instead. DORA recommends lightweight peer review at check-in plus automated detection through CI and monitoring, not a separate approval board.
How do you set up a quality gate without a dedicated tool like SonarQube?
Use what your Git host already provides: GitHub branch protection with required status checks and reviewer approvals, or GitLab MR approval rules with required approvals and Code Owners. Both can require checks to pass and conversations to resolve before a merge is allowed.
