Skip to content

Quality Gates and Approval Processes

4.5 Quality gates and approval processes

Quality gates ensure that no code or solution progresses to the next stage without meeting defined standards. Each gate includes clear criteria and an accountable role for approval.

4.5.1 Pre-Merge Quality Gate

  • Purpose: Ensure code quality and prevent bugs from entering the main branch.
  • Checks:
  • Automated unit tests must pass.
  • Code review completed (peer or tech lead).
  • Static analysis/linting checks pass.
  • Code coverage threshold met (if defined).
  • Sign-off: Developer + Reviewer/Tech Lead approve merge request.

4.5.2 Pre-Integration Quality Gate

Ensures that the code is stable after merge when integrated with the rest of the system.

Checks:

  • Integration tests pass against dependent services.
  • Sign-off: Technical Lead / DevOps / QA Engineer confirms successful integration.

4.5.3 Pre-Release Quality Gate

Ensure the solution is production-ready and meets business and technical requirements.

  • Checks:
  • All system tests and regression suites pass.
  • Non-functional tests (performance, security, usability) executed as required by project risk.
  • Exploratory testing completed, no critical bugs open.
  • UAT executed successfully against acceptance criteria.
  • Sign-off:
  • QA Engineer confirms functional and regression coverage.
  • Product Owner signs off on business acceptance.
  • Architect signs off that architectural standards (performance, scalability, security, compliance) are met.

4.5.4 Release Quality Gate

After the solution has passed the pre-release gate and is approved for production, the release gate focuses on verifying that the deployment or distribution process delivers the tested build correctly, without introducing new issues. Unlike pre-release, the goal is not to repeat full testing but to confirm that what was tested is what customers receive.

  • Checks:
  • Confirm the deployed build, image, or installer matches the pre-release approved version (checksum, version tag). Deployment validated in staging environment.
  • Validate packaging or installer integrity (desktop software).
  • Ensure configuration matches expectations (URLs, credentials, feature flags, runtime settings).
  • Confirm scaling rules, monitoring, and alerting are active (for cloud/web).
  • Run smoke tests to validate key functionality in production (e.g., login, homepage, API health checks). Production smoke tests must be safe, non-destructive and approved.
  • Platform-specific considerations
  • Web/Cloud Applications:
    • Deployment validated in production.
    • Basic smoke tests confirm service availability and key workflows.
    • Monitoring/logging is live and functioning.
  • Desktop/Packaged Software:
    • Installation tests on supported environments confirm the package installs and runs.
    • Dependencies (runtimes, libraries, drivers) included and correctly configured.
    • Optional beta testing or first-customer deployment for added safety.
  • Sign-off:
  • DevOps confirms deployment succeeded and the environment is stable.
  • QA Engineer confirms smoke/installation tests pass.
  • Product Owner finally approves to distribute to customers or make a public release.
  • For desktop/packaged software releases only: the Release Manager (when assigned) confirms release coordination and readiness for distribution.