·
9 min
Quality Gates: Automated Release Checks in the CI/CD Pipeline
Roman Kirchmeier - Autemos
A quality gate is an automated pass/fail threshold in the CI/CD pipeline that releases or stops every code change against fixed conditions. Meet all criteria and the pipeline continues. Miss even one and the build stops, blocking the release.
Poor software quality cost the U.S. economy an estimated 2.41 trillion dollars in 2022 (CISQ, 2022). These gates catch those defects before they reach production. This guide shows what a gate is, which criteria belong in one, and how to set sensible thresholds instead of vanity numbers.
In short: A quality gate checks every code change automatically against fixed conditions such as test coverage, defect count, and security checks, and blocks the release on any breach. SonarQube defines it as a "set of conditions against which the code is measured". Good gates measure new code rather than 100 percent coverage of the whole codebase.
Figure 1: A quality gate condenses fixed conditions into one yes or no per code change.
What is a quality gate?
A quality gate is a set of fixed release conditions that a pipeline measures every code change against. Passing means moving to the next step. Failing means a stop.
The SonarQube documentation puts it plainly: "A quality gate consists of a set of conditions against which the code is measured during analysis." (SonarQube). A gate answers exactly "one question: is my project ready for release?" (SonarQube).
A gate is not a single test. It is the decision rule that condenses many test results and analysis values into one yes or no. In a continuous testing pipeline it sits at the transitions between build, test, and deployment.
Do not confuse the gate with the CI/CD pipeline itself. The pipeline runs steps; the gate decides between two steps whether to continue or stop. A team can define several gates: a fast one after the unit tests, a stricter one before the deployment to production.
Which criteria belong in a quality gate?
Figure 2: Typical gate criteria with example thresholds that measure new code rather than the whole codebase.
A gate holds measurable criteria such as test coverage, test pass rate, static code analysis, security checks, and a performance budget. Each criterion gets a clear threshold at which the gate blocks.
SonarQube's built-in "Sonar way" gate checks mainly new code: zero new issues, 100 percent reviewed security hotspots, plus configurable thresholds for coverage and duplication (SonarQube). This principle is called "Clean as You Code".
The table below lists typical gate criteria with example thresholds and the reason behind each.
Criterion | Example threshold | Why |
|---|---|---|
Coverage on new code | ≥ 80 % | New logic is tested without blocking on legacy debt |
Test pass rate | 100 % green | A single red test signals an open risk |
New static issues | 0 | No fresh code smell or bug slips through |
Security hotspots | 100 % reviewed | Every security-relevant spot is assessed |
Known vulnerabilities | 0 critical/high | No exploitable hole ships in the release |
Duplication on new code | < 3 % | Less copy-paste cuts later maintenance |
Performance budget | e.g. LCP < 2.5 s | Load-time regressions surface early |
Not every team needs all seven criteria. A new web project often starts with pass rate, coverage, and static analysis. Security and performance gates get added once the product ships to production.
Separate hard conditions from soft ones. A hard condition stops the build at once, such as a critical vulnerability or a red core test. A soft condition raises only a warning, such as slightly dropped coverage. That keeps the gate strict where it counts and tolerant on the rest.
How does a quality gate work in the pipeline?
Figure 3: A gate runs four steps in the pipeline, from the check to release or stop.
A gate runs four steps in the pipeline: execute checks, collect results, evaluate against the thresholds, and release or stop the build. The flow stays the same at the unit, integration, or E2E stage.
Execute the checks. After the build, tests, static analysis, and security scans start automatically.
Collect the results. The pipeline gathers coverage, defect counts, and report data from every run.
Evaluate against the thresholds. Each value gets compared to its defined threshold.
Release or block. If all conditions pass, the build continues. If not, the pipeline stops.
Jenkins records test results after each run and marks the build UNSTABLE on failing tests (Jenkins). That keeps the trend visible even on a red gate, so the pipeline does not just abort without a signal.
Placement decides the feedback speed. Early gates check fast unit tests and static analysis in minutes, so developers see the fault right away. Late gates check slower E2E, security, and performance runs shortly before deployment. A gate right after each commit keeps the feedback short and the fault small.
Which quality gates make sense and which do not?
Sensible gates measure new code and block real risks; poor gates demand vanity numbers such as 100 percent coverage of the whole codebase. A high percentage on its own says little about test quality.
A gate rule set to 100 percent test coverage of the entire codebase sounds strict, yet in practice it mostly produces token tests with no real assertions. SonarQube's "Clean as You Code" principle starts exactly here: it measures coverage on the new code and leaves existing legacy debt untouched (SonarQube). Early checks from shift-left testing feed the gate clean results long before a change reaches the merge.
These patterns lead to gates that cause more frustration than value:
Coverage of the whole codebase as a hard threshold instead of the new code
Flaky tests that turn the gate red at random and erode trust
Too many criteria at once, so nobody knows why a build went red
Thresholds set without team consensus, so they get worked around
A good gate is strict on new code, tolerant of legacy debt, and clear to everyone on the team.
Thresholds are not a one-time decision. Start deliberately lower, say 70 percent coverage on new code, and raise the number once the team holds the discipline. A gate that blocks half of all merges for no clear reason gets worked around and loses its effect.
How do quality gates help in regulated industries?
Figure 4: Poor software quality cost the U.S. economy an estimated 2.41 trillion dollars in 2022 (CISQ).
In regulated industries, gates give the verifiable proof that each release met defined quality and security criteria. The gate result becomes an archivable release record for audits.
In client projects we see banks keep the logged gate result per release to show auditors exactly which tests passed, with no gaps. How that plays out with audit trails and four-eyes approval is covered in the article on test automation in regulated banks.
A gate in a regulated pipeline often replaces manual sign-off logs. Instead of a signature on paper, the system records per release which criteria passed, when, and with what result. The four-eyes review stays in place as a step, and the technical check runs reproducibly with no gaps.
That evidence only counts when the tests behind it run reliably. DORA links continuous testing to "a low error rate in production" (DORA, 2024). Autemos is an AI-powered test automation platform that runs tests across web, mobile, API, and desktop in one pipeline. Tests recorded with the AI Recorder run straight in the CI/CD path and produce repeatable report data that a gate can evaluate.
Frequently asked questions
What is the difference between a quality gate and a test?
A test checks a single behaviour and returns one result; a gate combines many such results plus analysis values into one release decision. The test says "green or red", the gate says "ready to release or not".
Should a quality gate block the build on every failure?
A gate should block on real risks, not on every bit of noise. Failing security or core tests stop the build; unstable flaky tests belong in quarantine so they do not turn the gate red at random and undermine trust.
What test coverage should a quality gate require?
A gate should measure coverage on new code, and around 80 percent is common. A hard 100 percent threshold on the whole codebase mostly produces token tests. SonarQube's "Clean as You Code" principle checks the freshly changed code for that reason.
Where in the CI/CD process does a quality gate sit?
A gate sits at the pipeline transitions: after the build, after the integration stage, and before deployment. Early gates check unit tests and static analysis; late gates check E2E, security, and performance criteria before release.
Are quality gates mandatory in regulated industries?
No law names "quality gate" verbatim, yet regulated industries require traceable release evidence. An automated gate delivers exactly that proof per release and replaces manual sign-off logs with reproducible, archivable check results.
Conclusion
A quality gate makes the release decision objective: fixed criteria, clear thresholds, an automatic yes or no. The strongest gates measure new code, block real risks, and stay clear to the whole team. Vanity numbers such as 100 percent coverage of the full codebase cost time without lifting quality.
At an estimated 2.41 trillion dollars in cost from poor software quality (CISQ, 2022), every blocked bad release pays off. In regulated industries, gates deliver the audit evidence that reviewers expect.
Want to build sensible quality gates into your pipeline and automate tests across every platform? Talk to our team about your specific CI/CD setup.
