Trunk-Based Quality Gates
Trunk-based quality gates keep the main branch deployable by running the full quality pipeline on every push, so a broken trunk is caught at the push that broke it, not at a later merge.
Definition
Trunk-based quality gates are the practice of running the complete build, test, and analysis pipeline on every push to the main branch — and blocking the push on failure — so that the trunk is always deployable and a regression is attributed to the commit that introduced it, with short-lived branches for work in progress.
Context and scope
Applied in continuous integration, trunk-based development, and any team that wants the main branch to be a deployable artifact at every commit.
Common misconceptions
- Trunk-based means no branches — it means short-lived branches (hours, not days); the trunk is the integration point, not the only workspace
- Quality gates on every push are too slow — they are too slow if the pipeline is slow; the fix is a fast pipeline, not skipping the gate
Anti-patterns
- Allowing broken pushes to merge and fixing forward, so the trunk is broken until the fix lands and deploys are blocked
- Running the full pipeline only on a nightly schedule, so a broken push is not caught until the next day and many commits are suspect
Related concepts
Authoritative source
What it is
Trunk-based quality gates are the practice of running the complete build, test, and analysis pipeline on every push to the main branch — and blocking the push on failure — so that the trunk is always deployable and a regression is attributed to the commit that introduced it, with short-lived branches for work in progress. Applied in continuous integration, trunk-based development, and any team that wants the main branch to be a deployable artifact at every commit. The unit of delivery is the deployable artifact plus its configuration, and the goal is to move changes to production safely, quickly, and reversibly.
How it works
Safety comes from small batches (less change per deploy means less blast radius), automated canaries (a bad change is caught at 1% before it reaches 100%), and reversible deployments (rollback is the default escape, not a rewrite). Speed comes from pipeline parallelism and eliminating the manual gates that batch up changes. Every step produces evidence — test results, scan output, canary metrics — that the next step consumes.
When to apply and pitfalls
Apply whenever the cost of an incident exceeds the cost of the pipeline that prevents it. The pitfall is optimizing deploy speed without investing in the observability and rollback that make speed safe — fast deploys of broken code just reach the outage sooner. Another is treating the pipeline as a checklist rather than a feedback loop that improves with each deployment.