Capability 02 of 04 · Delivery Management
Merge & Deploy
How PRs flow from creation to production - throughput, automation, and conflict handling.
5
maturity levels
15
practices
15
guides
L1 · Stage 01Ad-hoc
Practices - what it looks like3 guides
- Human review and merge on every PRManual PR review with manual merge is the baseline state for most engineering teams.guide→
- 10 PR/day capacityTen PRs per day is the typical throughput ceiling for a manual review-and-merge process on a team of 6-10 developers.guide→
- Manual deploy or simple CDManual deploy or simple CD covers the full spectrum of L1 deployment practice: from "someone SSHes into the server and runs git pull" to "merging to main triggers a pipeline that dguide→
Criteria - what to measure
- 01Pull requests are reviewed before merge
- 02The team ships pull requests regularly
- 03Basic CD pipeline exists (even if simple or manually triggered)
- 04Deploy frequency is at least weekly
L2 · Stage 02Guided
Practices - what it looks like3 guides
- Basic merge queuesA merge queue serializes pull requests that are ready to merge, ensuring that each PR is tested against the latest state of the target branch before it actually merges.guide→
- Auto-rebaseAuto-rebase is the practice of automatically keeping pull request branches up to date with the target branch without requiring the developer to manually run `git rebase main` or `gguide→
- CD pipeline with gatesA CD pipeline with gates is a deployment pipeline that has explicit checkpoints between stages.guide→
Criteria - what to measure
- 01Merge queue is implemented (GitHub merge queue, Mergify, or equivalent)
- 02Auto-rebase is enabled for PRs targeting main branch
- 03CD pipeline includes at least one gate (tests pass, security scan, approval)
- 04Merge conflicts are detected and flagged before review is requested
- 05Deploy frequency is at least daily
L3 · Stage 03Systematic
Practices - what it looks like3 guides
- Policy-based merge rulesPolicy-based merge rules replace ad-hoc human judgment about when and how to merge with codified, machine-enforced criteria.guide→
- Deterministic ordering + conflict detectionDeterministic ordering means the merge queue processes PRs in a defined, predictable sequence rather than in arbitrary arrival order.guide→
- Max 2 CI rounds per PR (Stripe benchmark)The "max 2 CI rounds per PR" benchmark comes from Stripe's engineering culture, where one of the key efficiency metrics for their agent-assisted development program (the Minions moguide→
Criteria - what to measure
- 01Policy-based merge rules are enforced (OPA, branch protection, or equivalent)
- 02Deterministic merge ordering with conflict detection prevents concurrent merge failures
- 03PRs require a maximum of 2 CI rounds before merge (Stripe benchmark)
- 04Merge rules are versioned as code and reviewed when changed
- 05PRs exceeding 2 CI rounds are flagged for investigation
L4 · Stage 04OptimizedMost teams aim here
Practices - what it looks like3 guides
- Green = auto-merge → auto-deployGreen = auto-merge → auto-deploy is the L4 delivery pattern where a pull request that passes all required CI checks and satisfies all policy criteria is automatically merged and thguide→
- 50+ PR/day throughputFifty or more PRs per day is the throughput milestone that marks the transition from "AI-assisted development" to "AI-augmented engineering at scale." At 10 PRs/day (L1), human revguide→
- Canary/progressive deployment auto; verifiable provenance per change (Dapr 1.18 cryptographic tamper-evident agent traces; record model + runtime)Automated canary and progressive deployment is the practice of rolling out changes to a small percentage of production traffic first, automatically monitoring key metrics during thguide→
Criteria - what to measure
- 01Green-classified PRs auto-merge and auto-deploy without human intervention
- 02Team throughput exceeds 50 PRs per day
- 03Canary or progressive deployment is automated (no manual rollout decisions)
- 04Auto-deploy includes automated rollback on error rate threshold breach
- 05Merge queue wait time is under 10 minutes
L5 · Stage 05Autonomous
Practices - what it looks like3 guides
- 1000+ merges/week (Stripe scale)1000+ merges per week is the throughput level that Stripe's engineering organization achieved with their AI-assisted development program, published as the "Minions" model.guide→
- Agent produces PR → CI passes → merge → deploy → observeThe full autonomous delivery loop - agent produces PR, CI passes, merge, deploy, observe - is the L5 state where code moves from conception to production without any required humanguide→
- Rollback is agent-drivenAgent-driven rollback is the practice of having AI agents detect production regressions, determine the root cause PR, initiate and execute the rollback procedure, communicate the iguide→
Criteria - what to measure
- 01Merge throughput sustains 1,000+ merges per week
- 02Full autonomous pipeline: agent produces PR, CI passes, merge, deploy, observe - no human in the loop
- 03Rollback is agent-driven (agent detects regression, reverts, and opens fix PR)
- 04Mean time to rollback is under 5 minutes from anomaly detection
- 05Agent-driven rollbacks succeed without human intervention 95%+ of the time
From the Field
Recent releases, projects and discussions the AI Radar classified into this capability.
release
rust-v0.119.0-alpha.24
discovered
AI-powered news app with AutoLoop for Product Market Fit — controlled by ControlNews.md, powered by Claude
release
release
discovered
A declarative configuration deployment tool
release
[email protected]
discussion
Why do ci pipeline failures keep blocking deployments when nobody can agree on who owns the fix
discovered
Android release browsing, kept clean.
Which level is your team at in Merge & Deploy?
The criteria above are what we check in a facilitated assessment. Run it yourself to place this capability, see which gates you have passed, and compare it against the other 3 in Delivery Management.
Start the assessment →