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 01Assisted
Practices - what it looks like3 guides
- Merging is a manual act: someone clicks the button on every changeNothing moves unless a person moves it: every change reaches main because someone decided the moment had come and clicked the button.guide→
- Merge capacity set by how fast humans can reviewTen 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 CDL1 deployment, from SSH and git pull to a pipeline that fires on merge. Either way there are no gates, no progressive rollout and no automated rollback.guide→
Criteria - what to measure
- 01Merging is a manual step performed by a person on every change
- 02The team merges pull requests at least weekly
- 03Basic CD pipeline exists (even if simple or manually triggered)
- 04Deploy frequency is at least weekly
L2 · Stage 02Delegated
Practices - what it looks like3 guides
- CD pipeline with gates; agent commits come from a distinct bot identity, never a developer's accountA CD pipeline with gates is a deployment pipeline that has explicit checkpoints between stages.guide→
- 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-rebasePR branches are kept current with the target branch automatically, so nobody runs git rebase main by hand every time another PR lands.guide→
Criteria - what to measure
- 01CD pipeline includes at least one gate (tests pass, security scan, approval)
- 02Merge queue is implemented (GitHub merge queue, Mergify, or equivalent)
- 03Auto-rebase is enabled for PRs targeting main branch
- 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 rules; agents push with short-lived GitHub App or OIDC tokens and never hold deploy secrets; agent output lands as a stack of dependent, independently reviewable branches rather than one 1,000-line PRPolicy-based merge rules replace ad-hoc human judgment about when and how to merge with codified, machine-enforced criteria, and they expect agent output to arrive as a stack of dependent, independently reviewable branches rather than one thousand-line pull request.guide→
- Deterministic ordering + conflict detection (cross-vendor agent PR pairs conflict at 41.7% vs 19.8% intra-vendor - standardize the fleet or serialize the merges)Deterministic ordering means the merge queue processes PRs in a defined, predictable sequence rather than in arbitrary arrival order.guide→
- A published cap on CI rounds per PR, and the team tracks itStripe's efficiency benchmark: a PR should reach green within two CI runs. A third round means the agent is guessing rather than reasoning.guide→
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 small, published maximum number of CI rounds before merge, and the team tracks it
- 04Merge rules are versioned as code and reviewed when changed
- 05PRs exceeding 2 CI rounds are flagged for investigation
L4 · Stage 04GovernedMost teams aim here
Practices - what it looks like3 guides
- A green verdict flows straight to production without a second queue or a second approval - while high-impact actions (token creation, production credentials, webhook edits) require a fresh human re-authentication (GitHub proof of presence)A green verdict flows straight to production: no second queue, no second approval, no waiting for someone to act on a decision that has already been made.guide→
- Throughput well above the pre-agent baseline, with the merge path no longer the constraintAt 50+ PRs a day, reviewing every one by hand stops being possible: the constraint moves to automated policy, merge queues and selective human review.guide→
- Canary/progressive deployment auto; verifiable provenance per change, with AI-assistance disclosure enforced in CI rather than by convention (Linux 7.2 carried 1,111 `Assisted-by` commits, and at least one maintainer strips the tags)Changes go to a slice of traffic first and metrics decide the rest - automatic promotion or automatic rollback with no human in the loop - and every change carries verifiable provenance, with AI-assistance disclosure enforced by CI rather than left to convention.guide→
Criteria - what to measure
- 01Green-classified PRs auto-merge and auto-deploy without human intervention
- 02Merge throughput has risen substantially against the pre-agent baseline, and the merge path is no longer the constraint on delivery
- 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 05Self-improving
Practices - what it looks like3 guides
- Merge volume limited by product decisions, not by the merge path1000+ 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 → observe (n8n model: release lifecycle fully delegated to bots)The full L5 delivery loop: an agent implements a spec, opens a PR, CI validates it, the merge queue lands it, CD deploys it and observability watches.guide→
- Rollback is agent-drivenAn agent detects the regression, finds the PR that caused it, rolls it back and tells the team, without waiting for a human to make those calls.guide→
Criteria - what to measure
- 01Full autonomous pipeline: agent produces PR, CI passes, merge, deploy, observe - no human in the loop
- 02Rollback is agent-driven (agent detects regression, reverts, and opens fix PR)
- 03Merge throughput is limited by product decisions rather than by the merge path itself
- 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
openai/codex
discovered
AI-powered news app with AutoLoop for Product Market Fit — controlled by ControlNews.md, powered by Claude
release
google-gemini/gemini-cli
release
Kilo-Org/kilocode
discovered
A declarative configuration deployment tool
release
n8n-io/n8n
article
Engineering an Autonomous SDLC at Scale at Roblox
article
Why AI task-level productivity doesn't translate to organizational throughput
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 →