A quality gate is a decision boundary
A quality gate is not merely a list of CI commands. It is a rule that determines whether a change may move to the next stage: merge, release, or demo.
A verification harness collects signals, while the gate interprets them in the context of a decision. A passing test and permission to merge are different things.
| Layer | Role |
|---|---|
| Verification harness | Runs tests, lint, type-check, build, and other sensors |
| Quality gate | Defines which results block the next transition |
| Human review | Evaluates context, risk, and what CI cannot formalize |
| Branch or release policy | Sets required conditions for a specific action |
Blocking and advisory checks
An unstable or very slow test should not be made blocking without thought. A red status should be rare, understandable, and connected to a concrete action.
| Status | Behavior | Examples |
|---|---|---|
| Blocking | The transition is forbidden without a pass | Build, type-check, deterministic unit and integration tests |
| Advisory | The result needs review but is not an automatic veto | AI semantic review, exploratory check, coverage delta |
| Informational | Context for a person without changing status | Metrics, an additional report, or recommendations |
What can belong in a PR gate
- Compilation, build, or type-check.
- Unit and integration tests.
- Lint and formatting.
- A scan for accidentally committed secrets.
- Dependency audit when configured and understood by the team.
- Human approval after diff review.
An explainable failure
A red pipeline should explain more than failed status. A person should quickly learn which check failed, where the log or report is, the most likely cause, and when a rerun is justified.
- Name the specific check that failed.
- Link to the relevant log or report artifact.
- Separate confirmed facts from a cause hypothesis.
- Describe the condition for rerun, rollback, or manual investigation.
- Do not turn reruns into a way to hide a stable regression.
Example gate for a refund inbox change
For a refund-request sorting change, this gate separates technical evidence from the acceptance decision. Even fully green CI does not remove human review of the diff and business context.
| Check | Status |
|---|---|
| Backend build | Blocking |
| Unit and integration tests | Blocking |
| Frontend lint and type-check | Blocking |
| Secret scan | Blocking |
| AI semantic review | Advisory |
| Reviewer approval | Required human condition |
Canonical lesson source · JavaRush
Open JavaRush material