Quality Gates: Your Automated Code Quality Checklist
A quality gate is an automated checklist that asks, 'Is this code ready to release?' It runs in CI/CD to enforce standards on metrics like bugs and test coverage, blocking merges that fail. The footgun is using one gate for all projects; tailor rules to.
WHY IT EXISTS: Quality gates were created to move code quality from a subjective, manual review process to an automated, consistent, and enforceable policy. They ensure that all code, regardless of the author or reviewer, meets an objective minimum standard before it can be merged or released, preventing the slow decay of a codebase.
THE MENTAL MODEL: Think of a quality gate as a bouncer for your main branch. It has a strict, non-negotiable checklist (e.g., 'no new blocker bugs,' 'at least 80% test coverage on new code'). If your code doesn't meet every item on the list, it's denied entry. This makes quality standards objective and automatic, removing the need for reviewers to manually police basic hygiene.
HOW IT WORKS: A quality gate is a set of conditions applied during code analysis. Each condition consists of a metric, a comparison operator, and an error value (e.g., new_bugs > 0). These metrics cover reliability (bugs), security (vulnerabilities), maintainability (complexity), and test coverage. If any single condition fails, the entire gate status becomes 'Failed.' This status is then reported back to the CI/CD pipeline and the code repository, often as a pull request decoration that can block the merge button.
WHEN TO USE IT: Use quality gates in any project with a CI/CD pipeline to enforce a consistent quality policy. They are essential for team-based development to provide fast, automated feedback on pull requests. This prevents merges that would introduce new issues, decrease test coverage, or add significant technical debt.
WHEN NOT TO USE IT: Avoid applying a single, generic quality gate across all applications. A critical internal framework should have much stricter requirements than a less critical internal tool. When first introducing a gate to a legacy project, start with lenient rules and tighten them over time to avoid halting all development and blocking necessary small fixes.
ONE CANONICAL EXAMPLE: A common quality gate for a web application's pull requests might have these conditions applied only to the new code: New Blocker Issues > 0 (FAIL) New Critical Issues > 0 (FAIL) Coverage on New Code < 80% (FAIL) Duplicated Lines on New Code > 3% (FAIL) If a developer submits a pull request with a new critical bug or only 75% test coverage on the new lines they wrote, the quality gate fails. The CI pipeline reports this failure, and the repository platform can be configured to block the 'Merge' button until the issues are fixed.
Read the original → docs.sonarsource.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.