As test suites and pipelines grow, teams need clear rules for when a build is considered good enough to move forward. Quality gates formalise these rules by defining conditions that must be met before code can be merged, deployed or released.
Defining Quality Gates in a Pipeline
A quality gate is a set of checks—such as tests passing, coverage above a threshold or no new critical issues—that a change must satisfy. Instead of subjective decisions on each build, gates provide consistent, automated criteria for quality.
Example quality gate conditions:
- All unit and API tests pass
- No critical or blocker issues in static analysis
- Minimum 80% coverage on new code
- No increase in open security vulnerabilities
- Key end-to-end smoke tests green in CIBy making gates explicit, you create transparency about what “good enough to merge” means for your organisation.
Common Mistakes
Mistake 1 — Having no clear gate definition
This leads to inconsistent decisions.
❌ Wrong: Relying on whoever is on duty to decide if a failing test or low coverage is acceptable.
✅ Correct: Agree on a small set of documented conditions that must be met.
Mistake 2 — Copying another team’s gates blindly
This ignores context.
❌ Wrong: Applying the same thresholds regardless of system risk or maturity.
✅ Correct: Tailor gates to your domain, architecture and current capabilities.