Quality gate
In software delivery, a quality gate is a checkpoint in the build or release pipeline that a change must pass before it moves to the next stage, defined by measurable conditions such as every test passing, no new critical static-analysis findings, or a passed smoke test on staging. A gate is pass or fail, applied to every change, and evaluated by the pipeline rather than argued in a meeting.
The longer version
A gate sits at a stage boundary: between commit and merge, between merge and deployment to staging, between staging and production. Its conditions are written down and the pipeline evaluates them automatically, blocking the change on a failure and recording why. Typical conditions are the unit and integration suites passing, security scanning reporting no new high-severity findings, a performance budget holding, and, before production, a smoke test on the staged build. The result is shown on the change itself, so the reason for a block is a fact rather than a rumour.
The phrase also names an inspection point on a manufacturing line and the stage gate that ends a project phase; this page is about the software pipeline sense. Within software the nearest confusion is with the go/no-go decision. A gate is automatic, per change, and narrow: it checks what a machine can measure. A go/no-go is human, per release, and wide: it weighs what the gates passed alongside what no gate can see. Entry and exit criteria are the same idea applied to a test phase rather than a pipeline stage. A gate in a QA process is the neighbouring sense: a question with a named owner, answered by a person rather than a pipeline.
Gates fail by being negotiable. A gate that can be bypassed with a flag or a comment is a suggestion, and the bypass becomes the default the first week a deadline lands on it. They also fail by measuring the wrong thing: a coverage threshold is satisfied by tests that assert nothing, and a gate on zero open defects produces defects reclassified as improvements. A gate earns its place when its condition is cheap to evaluate, hard to game, and blocks a failure the team has shipped before. The rest are ceremony that slows every change.
Common questions
What is a quality gate in CI/CD?
A stage in the pipeline that evaluates written conditions against a change and blocks it on failure: the test suites pass, static analysis finds no new critical issues, coverage does not fall below the agreed floor, the smoke test on staging passes. The pipeline enforces it on every change without a person deciding, and the outcome is recorded on the change.
Is a quality gate the same as a gate in a QA process?
A gate in a QA process is a question with a named owner, asked between two activities: does the story match the definition of done, can a stranger reproduce the finding. A quality gate is the pipeline's version of the same idea, with the owner replaced by a written condition a machine evaluates on every change. The process gate can be argued; the quality gate only passes or fails.
What conditions should a quality gate check?
Conditions that are cheap to evaluate, hard to satisfy dishonestly, and tied to a failure the team has shipped before. Passing test suites, no new critical security findings and a passing smoke test on staging meet all three. A bare coverage number meets the first and fails the second, since tests that assert nothing raise it, so it belongs in the gate only with review behind it.
Who sets the conditions of a quality gate?
The team that owns the pipeline stage, with QA proposing the test conditions, security the scanning thresholds and operations the deployment checks, and the whole set agreed by the engineering lead and written where the pipeline reads it. Conditions imposed from outside the team without that agreement are the ones that get bypassed, and conditions nobody owns are the ones that go stale.
Should a quality gate ever be bypassed?
A bypass is acceptable only as a recorded exception: a named person overrides a named gate for a named change, the reason is written on the change, and the override is reviewed afterwards. A gate that can be skipped with a flag in the commit message stops being a gate the first time a deadline lands on it. A gate that is bypassed often has the wrong condition, and that condition belongs in a review rather than in the pipeline.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.