Quality Gates in the CI/CD Pipeline: Building Four Stages

An effective checkpoint chain spans four stages: seconds at commit, minutes at the pull request, thorough before the merge, strict before the deploy. The order follows a single principle: the earlier a defect surfaces, the cheaper it is, so every check belongs as early as its runtime allows.

How do I build quality gates into a CI/CD pipeline?

In four stages, each with a clear time budget. The budget matters more than completeness: a pipeline that takes forty minutes gets bypassed.

Stage	Time budget	Checks
1: at commit (local)	under 10 seconds	Formatting, linting on changed files, secret scanning
2: at push / pull request	under 5 minutes	Unit tests, static analysis, coverage of changed lines, dependency check
3: before the merge	under 20 minutes	Integration tests, end to end tests of the main paths, build
4: before the deploy	as long as needed	Migration check, file classification, rollback path, smoke tests after rollout

Which check belongs in which stage?

The assignment follows runtime, not importance. An important check that takes ten minutes still does not belong in stage 1, otherwise stage 1 gets disabled and every check inside it is lost along with it.

• Stage 1 must go unnoticed. Anything that takes longer than a few seconds here feels like an interruption. Check only the changed files, not the whole project.
• Stage 2 is the real quality gate. This is where it is decided whether a change is even up for discussion. Everything a machine can decide belongs here, so that review is left with only the questions that genuinely need a human.
• Stage 3 is allowed to be expensive because it runs rarely. Integration tests against real dependencies, browser tests of the main paths.
• Stage 4 is not a code check. It concerns the release process itself, more on that below.

How does the pipeline stay fast?

With four measures that together make the difference between twenty minutes and three.

• Only check what actually changed. Static analysis and linters need the diff, not the whole repository.
• Cache intermediate results. Dependencies and build artifacts belong in the cache, not in every single run.
• Run in parallel, not in sequence. Tests, analysis, and build have no ordering dependency between them.
• Fail fast. If the linter fails in the third second, the twelve minute test suite no longer needs to run.

Why is the deploy gate the most important one?

Because it is the only stage where a defect is not just costly, but immediately visible. A code smell that slips through costs time in six months. An irreversible migration or a shipped file that never belonged on a server costs you tonight.

A deploy gate therefore checks different things than the stages before it:

• What is actually being transferred? Every file in the transfer scope needs to be classified: belongs on the server, belongs only locally, must never reach a server. Configuration files, credentials, and development tools fall into the third group.
• Is a schema change included, and is it reversible? A migration with no counterpart is a one way street. Before it runs: prove there is a backup.
• Is there a rollback path, and has it been tested? A rollback path that was never tried is just an assumption.
• Does something run afterward that checks success? A smoke test after rollout is the difference between "shipped" and "works".

None of these four questions can be answered with more tests. They concern the release process, not the code. That is why stage 4 needs its own dedicated barrier, see What Is a Quality Gate.

How do I introduce gates without blocking ongoing operations?

Start by observing, then start blocking, and always only for new code.

• Weeks 1 to 2: report only. Every check runs, none of them fails the build. You see how often each criterion would actually trigger.
• Week 3: enforce the clear cases. Failing tests and secrets in the code now fail the build. Nobody argues against these two.
• After that: draw a baseline and tighten what is new. The existing codebase is frozen as is, and full strictness applies to changed lines. Approach described in the article on static code analysis.

Frequently asked questions about quality gates in the pipeline

What is the difference between CI and CD?

Continuous Integration means merging changes frequently and checking them automatically. Continuous Delivery, or Deployment, means automatically shipping the checked state. The gates from stage 1 to 3 belong to CI, stage 4 belongs to CD.

Should the pipeline fail on every finding from static analysis?

No, only above a defined severity and only for new findings. Anyone who fails the build over every style comment ends up with workarounds instead of quality.

How do I deal with flaky tests?

Treat them as a problem in their own right, not as noise. A test that occasionally fails for no reason costs more than it is worth: it trains the team to rerun red runs instead of reading them. Either fix it or remove it.

Do I need a Git hook for stage 1?

A local hook is the usual approach, but it can be bypassed and it lives only on an individual machine. Do not rely on it alone: whatever stage 1 checks should run again in stage 2.

Which file in your last deploy actually had no business being on the server? If you cannot answer that right away, that is exactly the gap. Code Guardian classifies every file in the transfer scope and treats every migration as irreversible until proven otherwise.

Sources

• OWASP Top 10:2025, category A03 "Software Supply Chain Failures" (rationale for the dependency check in stage 2).
• ISO/IEC 25010:2023 (quality characteristics as the reference framework for gate criteria).

As of: July 27, 2026. General professional guidance; actual time budgets depend on project size and infrastructure.