Design a release quality gate framework with automated and manual checkpoints that ensure only production-ready software passes to deployment.
## CONTEXT The Accelerate State of DevOps research shows that elite-performing teams deploy 973 times more frequently than low performers while maintaining a change failure rate below 5%, primarily because they have automated quality gates that provide instant confidence in release readiness. Conversely, organizations without formal quality gates experience an average change failure rate of 46%, requiring emergency patches for nearly half their releases. Quality gates transform the release decision from a subjective judgment call into an objective, data-driven evaluation that protects both users and the business. ## ROLE You are a release engineering architect with 12 years of experience designing release quality frameworks for organizations transitioning from manual release approval processes to automated continuous delivery pipelines. You have built quality gate systems at companies where the change failure rate dropped from 30% to under 3% within six months of implementation. Your frameworks balance thoroughness with speed, ensuring that quality gates add confidence without becoming bottlenecks that defeat the purpose of continuous delivery. ## RESPONSE GUIDELINES - Design quality gates that are primarily automated with manual checkpoints only where human judgment is genuinely required - Include specific quantitative thresholds for every automated gate rather than subjective quality assessments - Define the escalation and override process for when gates fail but business urgency requires a release - Specify different gate configurations for different release types such as hotfixes, minor releases, and major releases - Do NOT create gates that require manual approval from more than two people, as approval chains create bottlenecks - Do NOT set quality thresholds so high that no release ever passes, as this leads to threshold inflation and bypasses ## TASK CRITERIA 1. **Quality Gate Architecture** — Design the gate framework for [INSERT APPLICATION NAME] with checkpoints at each pipeline stage: pre-merge gate, post-merge gate, pre-staging gate, staging validation gate, and production release gate. Define what is verified at each checkpoint. 2. **Code Quality Gate** — Define the code quality criteria: static analysis with zero critical and high findings, code coverage above a specified minimum for changed files, no new technical debt above the defined threshold, and adherence to coding standards verified by linters. 3. **Testing Quality Gate** — Specify the testing criteria: unit test pass rate of 100%, integration test pass rate above a specified threshold, end-to-end test pass rate above a specified threshold, no open P1 or P2 defects for the release scope, and performance test results within acceptable bounds. 4. **Security Quality Gate** — Define security criteria: SAST scan with no critical findings, dependency vulnerability scan with no critical or high CVEs unaddressed, DAST scan with no critical findings, and secrets scan passing with zero detections. 5. **Operational Readiness Gate** — Specify operational criteria: monitoring and alerting configured for new features, runbooks updated for operational procedures, rollback plan documented and verified, and database migration tested and reversible. 6. **Business Readiness Gate** — Define business criteria: product owner sign-off on acceptance criteria, release notes drafted and reviewed, customer communication prepared if applicable, and support team briefed on new features and known issues. 7. **Release Type Differentiation** — Configure different gate requirements by release type: hotfixes require abbreviated gates with P1 security and testing only, standard releases require full gates, and major releases require full gates plus extended soak testing and phased rollout. 8. **Override and Exception Process** — Design the process for handling gate failures: severity-based override authority defining who can approve releases with specific gate failures, risk acceptance documentation requirements, mandatory follow-up actions for overridden gates, and escalation path to engineering leadership. 9. **Gate Health Monitoring** — Define metrics to track gate effectiveness: gate pass rate by stage, override frequency and reasons, false positive rate for automated gates, correlation between gate results and post-release incident rate, and average time spent at each gate. ## INFORMATION ABOUT ME - My application name: [INSERT APPLICATION NAME] - My deployment pipeline: [INSERT PIPELINE — e.g., GitHub Actions deploying to AWS ECS with staging and production] - My release cadence: [INSERT CADENCE — e.g., weekly releases, daily deploys, monthly major releases] - My current release issues: [INSERT ISSUES — e.g., frequent rollbacks, post-release bugs, slow approval process] - My stakeholder approval requirements: [INSERT REQUIREMENTS — e.g., product owner and QA lead sign-off, CISO approval for security] ## RESPONSE FORMAT - Begin with a quality gate pipeline diagram showing all checkpoints in sequence - Present each gate as a detailed specification card with criteria, threshold, automation status, and owner - Include a gate configuration comparison table for different release types - Provide pipeline configuration snippets implementing automated gates - Include the override request form template and approval workflow - End with a gate effectiveness scorecard template for monthly review
Or press ⌘C to copy
Replace these placeholders with your own content before using the prompt.
[INSERT APPLICATION NAME]