Design and implement automated quality checks inside GitHub Actions, Jenkins, or GitLab CI – with go/no-go policies that your whole team agrees on and the pipeline enforces automatically.
A quality gate is an automated check in your pipeline that must pass before the pipeline proceeds. The most basic version is "tests must pass before merging." That is a quality gate, and most teams have it. What most teams are missing are the additional gates that cover the other ways software quality degrades before it reaches production.
Code that passes all tests can still fail quality standards in several ways: security vulnerabilities, dependency licensing issues, code coverage that has fallen below an agreed threshold, code style violations that indicate technical debt accumulation, and documentation that references deleted API endpoints. Gates can catch all of these automatically – without requiring a human to notice them in code review.
The reason most pipelines don't have enough gates is historical: gates were added one at a time in response to incidents, not designed as a coherent system. The result is usually good coverage on the things that have caused problems before, and gaps everywhere else. A structured quality gate design addresses the full surface area, not just the incident history.
Different gates belong at different points in the deployment pipeline. Placing gates correctly – blocking at the earliest point where a failure can be caught – minimizes the cost of failures and keeps CI fast enough that engineers don't work around it.
Pre-merge gates (pull request pipeline): These run on every pull request and must pass before the PR can be merged. They need to be fast – under 10 minutes total. Good candidates: unit tests, linting and type checking, code coverage threshold check, security dependency scanning, and a focused API test suite. End-to-end tests are generally too slow and too environment-dependent for PR gates.
Post-merge gates (main branch pipeline): These run after merge to the main branch and gate deployment to staging. They can be slower. Good candidates: full integration test suite, end-to-end smoke tests, performance baseline checks, and accessibility audits.
Pre-deploy gates (staging to production): These run before deploying to production and are the last automated line of defense. Good candidates: full regression run against staging, security scanning of the deployment artifact, and smoke test execution against the staging environment with production-like data.
Pre-release gates: For products with explicit release processes (mobile apps, major software versions), a final release gate validates the release candidate: all regression tests pass, known issues are documented with acceptance, and the release checklist is completed.
The gate that blocks the most consequential bugs is usually the pre-merge gate – catching issues before they reach the main branch. The gate that provides the most confidence before production is the pre-deploy gate against staging. Both are necessary; neither is sufficient without the other.
We implement quality gates in the CI/CD platform your team already uses. Each platform has its own patterns and constraints, and the implementation approach differs accordingly.
GitHub Actions: Quality gates are implemented as required status checks in branch protection rules. We configure the workflow files, set up the branch protection rules, and configure notifications so failures are surfaced to the right people. We also configure CODEOWNERS for automatically requesting reviews from the right team members when specific files change.
Jenkins: Quality gates in Jenkins use shared libraries and declarative pipeline stages with post-condition blocks. We write the pipeline configuration as code (Jenkinsfile), set up the shared library for common gate logic, and configure notifications to Slack or email for failures at specific stages.
GitLab CI: GitLab's native quality gate support is strong – we use protected branch rules, merge request approval rules, and GitLab's built-in security scanning integrations. For more complex gate logic, we use the extends syntax in .gitlab-ci.yml to share gate definitions across projects.
A quality gate that the team routes around is not a quality gate. The policy definition phase – deciding exactly what each gate checks and what counts as a pass – is as important as the implementation.
We run a structured policy definition session with the team before implementing any gates. In this session, we work through each proposed gate and get explicit answers to: what does "pass" mean, what is the threshold (100% unit test pass rate, or 95%?), who can override a failed gate and under what conditions, and what happens when a gate fails (hard block vs warning).
The override process is particularly important. A gate that can never be overridden will be bypassed when there is a legitimate time-sensitive reason to deploy despite a known issue. A gate that can always be overridden with a comment provides false confidence. The right policy is an explicit override process – documented, logged, and requiring named approval – that makes bypassing a gate a deliberate and visible decision.
We design and implement quality gate systems tailored to your pipeline and team. Tell us what you're working with and we'll scope the engagement.
Book a Free Call