Manual deploy or simple CD
L1 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.
- Pull requests are reviewed before merge
- The team merges pull requests at least weekly
- Basic CD pipeline exists (even if simple or manually triggered)
- Deploy frequency is at least weekly
- PR merge history showing manual approvals
- Deploy logs showing manual trigger or simple CD pipeline
What It Is
Manual 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 deploys automatically." Both are L1 in the context of AI-scale delivery. What they share is that the deployment process is either fully human-operated or only shallowly automated - there are no gates, no progressive rollout, no automated rollback, and no feedback loop between deployment and the next change.
Manual deployment in its purest form means a developer or operations engineer coordinates and executes every deploy manually. They pick the timing, run the deploy script, watch the logs, and decide whether it worked. Simple CD - the slightly more mature variant - automates the mechanics of deployment (trigger on merge, run the deploy command) but leaves everything else manual: timing, environment selection, rollback decisions, and monitoring.
Both patterns work acceptably when deployment frequency is low (weekly or biweekly releases), the codebase is small, and rollback is simple. They become constraints when deployment frequency needs to increase. At L1 with AI-assisted development, teams face a paradox: agents can produce working, tested code faster than ever, but the deployment process is still gated by manual steps that haven't been updated to match the new production rate.
The simple CD pattern - push to main, auto-deploy to production - is a common "upgrade" that teams make without recognizing its risks at scale. It works fine at 5 deploys per day. At 30 deploys per day, a single bad deploy in a fully automatic pipeline without gates or canary rollout can cause a production incident before anyone notices. Automation without safety is worse than manual deploy - it fails faster.
Why It Matters
- Deploy frequency is a DORA elite metric - elite performing teams deploy on demand, multiple times per day; L1 manual deploy is the starting point, not the destination, and the gap to elite is large
- Manual coordination creates a deploy bottleneck - in organizations where someone has to approve and watch every deploy, deploy frequency is bounded by that person's availability and attention span
- Simple CD without gates creates incident risk - automating deployment without automating validation or rollout strategy means problems propagate immediately to all users; one bad AI-generated commit can cause a full production outage
- Deployment fear inhibits shipping - teams with fragile or painful deploy processes deploy less often, batch more changes per deploy, and increase blast radius when something goes wrong; the manual deploy model tends to reinforce this fear
- The feedback loop is broken - without automated deployment, the loop from "agent writes code" to "code in production generating real-world signal" is slow; AI-assisted teams need fast feedback to validate that agent-produced code actually works in production
Getting Started
- Audit your current deploy process - write out every manual step. Who does it? How long does it take? What can go wrong? What's the rollback procedure? This audit will reveal where automation has the highest leverage.
- Measure your current deploy frequency - how many times per week does code reach production? Compare to how many merges to main happen per week. The ratio is your "deploy lag." A deploy lag of 10:1 (10 merges per deploy) means you're batching heavily and increasing blast radius.
- Add basic health checks to your deploy script - before treating deployment as automated, ensure that every deploy runs a health check endpoint after completion. If the health check fails, the deploy script should alert immediately. This is the minimum safety net.
- Set up a staging environment that mirrors production - if you don't have one, create it. All automated deploys should hit staging first. Staging is where you discover problems without user impact. Even a simple
docker-composestaging environment is better than deploying directly to production. - Implement a simple deployment pipeline in GitHub Actions or similar - trigger on merge to main: build, test, deploy to staging, run smoke test, deploy to production. This is "simple CD" done correctly: automated mechanics with basic safety checks. GitHub Actions, GitLab CI, or CircleCI can implement this in under a day.
- Define your rollback procedure and test it - manual rollback ("run this script to revert to the previous version") is acceptable at L1. What's not acceptable is not knowing how to roll back until you're in an incident. Document and test your rollback procedure before your next deploy.
The most common failure of simple CD is "deploy on every merge to main with no gates." If you implement simple CD, add at minimum: one post-deploy smoke test that hits your key endpoints. A deploy that fails a smoke test should alert immediately and pause further deploys. This turns simple CD from dangerous to merely basic.
Common Pitfalls
Treating "it deploys automatically" as "it deploys safely." Automation and safety are independent dimensions. A pipeline that auto-deploys on merge is automated but not safe without gates, health checks, and rollback automation. Teams that implement simple CD as "just add a deploy step to CI" often discover this distinction the hard way during their first production incident with a bad AI-generated change.
No staging environment. Deploying directly from CI to production without a staging environment means production is your test environment. At low deploy frequency, this is a calculated risk some teams accept. At high deploy frequency with AI-generated code, it's an incident waiting to happen. Staging doesn't have to be expensive - a lightweight environment with real application code and mocked external dependencies is sufficient.
Manual deploys with no runbook. "We just SSH in and run the deploy" is fine until the person who knows how to do it is on vacation, or until the deploy goes wrong at 2am. Every manual step in your deploy process should have a documented runbook. This is table stakes before any automation investment.
Deploying large batches. Teams on manual or simple CD tend to batch many merges into a single deploy event (deploy every Friday, for example). Large batch deploys have large blast radius: when something goes wrong, you're reverting many changes at once, and debugging which change caused the problem is painful. Smaller, more frequent deploys are safer even if each one requires more coordination.
No post-deploy monitoring. Deploying and walking away is not complete. Every deploy should have a defined observation window (15-30 minutes of monitoring key metrics: error rate, latency, key business events). Without this, you discover problems when users complain rather than when the metrics diverge. Simple CD without basic post-deploy monitoring is "deploy and hope."
How Different Roles See It
Bob's team deploys every two weeks as part of a release cycle that dates from before the team adopted CI. The release manager coordinates the deploy manually with the infrastructure team, which requires scheduling meetings and a deploy window. With AI-assisted development accelerating code production, Bob has developers asking "why aren't we shipping this faster?"
What Bob should do: Bob should audit the release cycle and find the manual steps that create the two-week cadence. Typically it's a combination of: manual deploy execution, lack of staging confidence, and habit. Bob should commission a "deploy on merge" pilot for one low-risk service: set up a pipeline that deploys to staging automatically on merge, runs smoke tests, and deploys to production with a one-hour observation window. If this works for 30 days without incidents, use it as the template for other services. The goal is to demonstrate that deploy frequency can increase without increasing risk - which is the prerequisite for getting buy-in to invest in proper CD infrastructure.
Sarah's developer satisfaction data shows that "deploy process" is a recurring frustration, specifically: "I merge code and it takes two weeks to get to users." She wants to reduce this lag but the infrastructure team says "deploys require coordination" and the process feels too embedded to change.
What Sarah should do: Sarah should calculate the business cost of the deploy lag. If the team merges 50 PRs per sprint and deploys every two weeks, there are 50 changes sitting in a "merged but not shipped" state for an average of one week each. That's 50 developer-weeks of work generating zero user value while waiting in a deploy queue. Framed as "we have $X of completed work that isn't in production," this becomes a business problem, not a developer preference problem. Sarah should use this framing to get permission for a deploy acceleration pilot, then measure the business impact: time-to-user for a feature from merge to deploy, and user-reported bug discovery latency (bugs found faster in production than in a two-week deploy batch).
Victor has set up a working GitHub Actions pipeline for his team's main service that deploys on merge to staging automatically. He wants to extend this to production but the infrastructure team is hesitant because "production deploys are special." Victor knows that without a proper CD pipeline, his agent-produced code is accumulating in staging and creating a big-bang deploy problem.
What Victor should do: Victor should propose a controlled production deploy pilot with explicit safety criteria: deploy to production only when staging smoke tests pass, include a 30-minute observation window with error rate alerts, and implement one-click rollback. He should offer to implement and monitor the first 10 production deploys personally. The infrastructure team's concern is risk - Victor should directly address risk, not dismiss it. A deploy with automated smoke tests, health checks, and rollback is demonstrably safer than a manual deploy with no automated validation. Victor should make that argument with data from the staging pipeline.
Further Reading
Where does your team actually sit on this?
This guide describes one level of one area. Run the assessment to place your team across all 16 areas, see which gates you have passed, and get a report you can take to your stakeholders.
Merge & Deploy