A quality gate is an automated checkpoint in your CI/CD pipeline that blocks code from advancing if it doesn't meet predefined criteria. These are also called test gates, q gates, or q-gate checkpoints. If tests fail, crash rates spike, or code coverage drops, gate stops build before it reaches production.
What are quality gates in practice? The purpose of gate checkpoints is simple: if-then rules wired into your pipeline. If test pass rate is below 98%, block merge. If crash-free rate drops below 99.5%, block release. If app binary exceeds 150MB, flag for review.
Quality gates matter more for mobile than for web. You can't hotfix a mobile app. A bug that reaches production stays there until next app store review completes. Quality engineering teams use gates to catch problems before build enters app store pipeline, because once it's there, rolling back is slow and expensive.
What quality gates should a mobile pipeline have?
A mobile CI/CD pipeline needs gates at four stages. Most teams only have gates at stage one.
Each gate has pass/fail criteria. If any criterion fails, pipeline stops. The team fixes issue and re-runs. No manual overrides without documented approval.
What are mobile specific quality gate criteria?
Web quality gates focus on code coverage, security scans, and response times. Mobile gates need additional criteria that web pipelines don't have.
Crash-free rate. Check Crashlytics or Sentry data. If crash-free rate on latest build drops below 99.5% during internal testing, block release. A 1% crash rate means 1 in 100 sessions crash. On an app with 100,000 daily users, that's 1,000 crashes per day.
App binary size. Mobile users care about download size. Set a gate that flags if APK or IPA exceeds your target (e.g., 100MB for APK, 150MB for IPA). This catches accidentally bundled assets or bloated dependencies.
Device compatibility. Run your test suite on a minimum device matrix (e.g., 6 devices covering 85% of your user base). The gate checks that tests pass on all devices in matrix, not just one.
Build signing validation. Verify that build is signed with correct certificate and provisioning profile. An unsigned or wrongly signed build wastes hours in app store submission process.
ANR rate (Android). Application Not Responding errors frustrate users. Gate on ANR rate staying below 0.5% during test execution.
UI regression. If you use screenshot comparison or Vision AI testing, gate on visual diff results. Drizz can validate that screens render correctly on real devices as part of test execution gate.
How do you set up a sonar quality gate for mobile?
SonarQube checks code quality: bugs, vulnerabilities, code smells, and coverage. A sonar quality gate defines thresholds that code must meet before merging.
The default SonarQube quality gate ("Sonar Way") requires:
- No new bugs (reliability rating A)
- No new vulnerabilities (security rating A)
- Code coverage on new code above 80%
- Duplication on new code below 3%
For mobile, SonarQube covers code quality gate (stage 1 in table above). It doesn't cover device testing, crash rates, or app binary size. You need SonarQube for code quality and a separate mobile testing gate for app quality.
If your sonarqube quality gate failed, check which condition wasn't met in SonarQube dashboard. Common mobile causes: low unit test coverage on new ViewModel code, security vulnerabilities in third-party SDKs, or code duplication from copy-pasted platform-specific implementations.
A complete mobile quality gate process combines SonarQube (code quality) with mobile test automation (app quality). One without other leaves gaps.
How do quality gates work in a mobile CI/CD pipeline?
Here's a GitHub Actions example with quality gates at each stage:
# .github/workflows/mobile-quality-gates.yml
name: Mobile Quality Gates
on:
pull_request:
branches: [main]
jobs:
code-quality-gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run unit tests
run: ./gradlew test
- name: Check coverage
run: |
COVERAGE=$(./gradlew jacocoTestReport | grep "Total" | awk '{print $3}')
if [ "$COVERAGE" -lt 80 ]; then
echo "Coverage ${COVERAGE}% below 80% gate"
exit 1
fi
- name: SonarQube scan
uses: SonarSource/sonarqube-scan-action@v2
- name: SonarQube quality gate
uses: SonarSource/sonarqube-quality-gate-action@v1
build-gate:
needs: code-quality-gate
runs-on: macos-latest
steps:
- name: Build Android APK
run: ./gradlew assembleRelease
- name: Check APK size
run: |
SIZE=$(stat -f%z app/build/outputs/apk/release/app-release.apk)
MAX=104857600 # 100MB
if [ "$SIZE" -gt "$MAX" ]; then
echo "APK size exceeds 100MB gate"
exit 1
fi
test-gate:
needs: build-gate
runs-on: ubuntu-latest
steps:
- name: Run smoke tests on real devices
run: drizz run --suite smoke --devices "Pixel8,iPhone15"
- name: Check pass rate
run: |
PASS_RATE=$(drizz results --format json | jq '.pass_rate')
if (( $(echo "$PASS_RATE < 98" | bc -l) )); then
echo "Test pass rate ${PASS_RATE}% below 98% gate"
exit 1
fi
Each job is a quality gate. If code-quality-gate fails, build-gate never runs. If build-gate fails, test-gate never runs. The pipeline enforces quality at every stage.
What are quality gates in project management?
Quality gates in project management are decision points where stakeholders review whether a project meets criteria before advancing to next phase. This is phase gate process (also called stage-gate or gate process) used in product development.
For mobile teams, project management gate typically happens at release readiness stage. The QA lead, engineering manager, and product manager review:
- Test execution results (pass rate, device coverage)
- Open bug count by severity
- Crash-free rate from internal testing
- Performance benchmarks (startup time, memory usage)
- Stakeholder sign-off on new features
This gate is human checkpoint that complements automated gates. A project gate review checklist for this stage includes test results, open bug counts, crash data, and stakeholder approvals. Automated gates catch measurable issues (test failures, coverage drops). The release readiness gate catches judgment calls (is this build good enough to ship?).
What are security quality gates?
Security quality gates verify that build doesn't introduce vulnerabilities. For mobile apps, security gates check:
- Dependency vulnerabilities (npm audit, gradle dependency check)
- API key exposure (no hardcoded secrets in build)
- Certificate pinning configuration (verify SSL pinning is active)
- Data encryption (local storage encryption on both platforms)
- Security quality gates in SDLC also include compliance checks for GDPR, HIPAA, or PCI-DSS depending on your industry
SonarQube handles some security scanning. For mobile-specific security (certificate pinning, storage encryption, API key leakage), you need mobile security tools like MobSF or manual security review.
What does a real mobile quality gate setup look like?
A fintech app team implemented four quality gates in their pipeline:
Gate 1 (PR merge): SonarQube with 80% coverage threshold and zero new vulnerabilities. Blocks merge to main. Catches 60% of code-level issues before they reach build.
Gate 2 (build): APK size under 80MB, IPA under 120MB, valid signing on both platforms. Catches bloated builds and signing issues before test execution.
Gate 3 (test): Smoke suite on 3 devices (pass rate above 98%), full regression nightly on 8 devices (pass rate above 95%). Drizz runs plain English tests on real devices with Vision AI. Catches functional regressions and device specific bugs.
Gate 4 (release): Crash free rate above 99.7% from 48 hours of internal testing, zero open S1/S2 bugs, QA lead sign-off. Catches issues that automated tests missed.
Before quality gates, team shipped bugs in 1 out of 4 releases. After gates, escaped defect rate dropped to 1 in 12 releases. The gate process added 20 minutes to each pipeline run but saved days of post-release debugging. Tools like Drizz handled test execution gate by running stable, selector-free tests on real devices, keeping gate reliable instead of blocked by flaky test failures.
FAQs
What are quality gates?
A quality gate is an automated checkpoint in a CI/CD pipeline that blocks code from advancing if it doesn't meet predefined criteria. Gates check test results, code coverage, security scans, crash rates, and other metrics. If any criterion fails, pipeline stops until issue is fixed.
What is a quality gate checklist template?
A quality gate checklist template defines criteria for each gate: code quality (coverage above 80%, no critical bugs), build validation (size limits, signing), test execution (pass rate above 98%, device coverage), and release readiness (crash-free above 99.5%, no S1/S2 bugs, stakeholder sign-off). Customize thresholds based on your app's risk tolerance.
What is a sonar quality gate?
A sonar quality gate is a set of conditions in SonarQube that code must pass before merging. The default "Sonar Way" gate requires reliability rating A, security rating A, coverage above 80% on new code, and duplication below 3%. It covers code quality but not mobile-specific concerns like crash rates or device compatibility.
What are quality gates in DevOps?
Quality gates in DevOps are automated enforcement points in CI/CD pipelines. They run checks at each pipeline stage (merge, build, test, deploy) and block progression when criteria aren't met. For mobile DevOps, gates include code analysis, build validation, real-device test execution, and release readiness checks.
What is phase gate process?
The phase gate process (also called stage-gate or gate process) is a project management framework where projects pass through decision checkpoints at each phase. For mobile releases, gate process typically includes requirements review, design review, code quality gate, test execution gate, and release readiness gate. Each gate has entry and exit criteria.
How do quality gates reduce mobile release risk?
Quality gates catch issues before they reach app store. Since mobile apps can't be hotfixed (you need an app store review for every update), catching bugs in pipeline is cheaper than catching them in production. Automated gates add minutes to pipeline but save days of post-release debugging and resubmission.
