Skip to content
SDETRole
SDETRole

Glossary · CI/CD and DevOps

Quality gate

Also called: quality gates, release gate, release gates

Definition

An automated pass/fail check in a pipeline, such as tests passing or coverage above a threshold, that must succeed before code can merge or ship.

A quality gate is a set of conditions a change must meet before it moves to the next stage: merge, deploy to staging, or release to production. Each condition is measurable and checked automatically, and if any fails, the pipeline stops. The gate replaces “someone thinks it looks fine” with an explicit, agreed bar.

Typical gate conditions

  • All blocking tests pass (unit, API, a smoke subset of end-to-end).
  • Line or branch coverage on new code does not drop below an agreed number.
  • No new critical or high findings from static analysis or dependency scanning.
  • Performance thresholds hold, for example p95 latency under 500 ms in a short load test.
  • The build is reproducible and the artefact is signed or versioned.

Example

A coverage gate in Jest. If coverage falls below these numbers, jest --coverage exits non-zero and the CI job fails:

// jest.config.js
module.exports = {
  coverageThreshold: {
    global: {
      branches: 80,
      lines: 85,
    },
  },
};

On its own this only fails a job. It becomes a gate when the job is a required status check in branch protection, so the merge button stays disabled until it passes. Tools such as SonarQube package several conditions into one named gate with a single pass/fail result.

Why it matters

Gates make the definition of “ready” visible and consistent. They also move arguments to the right time: the team debates the threshold once, when setting it, instead of on every release.

Common mistakes

  • Gating on numbers people can game. A hard 90% coverage rule invites tests that execute code without asserting anything. Gate on coverage of new code and review the tests themselves.
  • Flaky checks in the gate. A gate that fails randomly gets bypassed. Keep only deterministic checks blocking; run the rest as non-blocking with alerts.
  • Too many gates, too late. Ten conditions checked only before release produce a pile of failures nobody has time to fix. Put cheap checks early, on every pull request.
  • Silent overrides. If a gate can be skipped, log who skipped it and why.

Type to search across SDETRole.

Full-text search by Pagefind · runs in your browser Open search page →