The DevOps Checklist for Teams Moving from Manual Deploys

You are shipping on Thursday evenings because someone senior needs to watch the release. Staging does not match production. A rollback plan exists but has never been tested. Your cloud bill is a mystery.

You know this needs to change. You want automated deploys, reproducible environments, and the ability to ship during business hours. But where do you start? What do you build first? What order prevents you from getting stuck?

This is the checklist.

What you are actually building#

DevOps is often described as a culture or a mindset. In practice it is a specific set of technical capabilities:

• Continuous Integration — every commit is tested automatically
• Continuous Deployment — tested commits can reach production without a manual gate
• Infrastructure as Code — infrastructure lives in version control, reproducible and reviewable
• Observability — metrics, logs, traces, and dashboards that say what is wrong before a customer does

Skip one and the others compensate badly. A deployment pipeline with no observability means you deploy confidently and fail silently. Infrastructure as code with no CI means your changes are version-controlled but untested. Both are worse than having nothing, because they create the illusion of control.

The order that actually works#

Phase 1: Measure the baseline (Week 1)#

Before you change anything, measure:

• Deploy frequency — How often do you deploy to production? (Today: once or twice a month? This should become weekly or daily.)
• Lead time — Time from commit to production. (Today: weeks? This should be hours.)
• Time to recover — How long from "production is broken" to "production is fixed"? (Today: hours or days? This should be minutes.)
• Change failure rate — What percentage of deploys introduce a production incident? (Today: maybe 30–50%? This should be 15% or lower.)

These numbers are your before/after. They prove whether the work is actually working.

Phase 2: Codify the infrastructure (Weeks 1-3)#

Write Infrastructure as Code for everything—networks, databases, load balancers, security groups, environment configuration.

Do not rebuild from scratch. Import what you have running. A managed infrastructure tool (Terraform, CloudFormation) can read your existing resources and generate the code. It is not perfect, but it is faster than rewriting by hand.

Why this first: You cannot have reproducible environments without this. You cannot confidently rebuild staging without this. You cannot do progressive rollouts without this. Everything downstream depends on it.

What you will find: Environments that are different in ways nobody knew. A security group rule nobody remembers adding. A database parameter that was changed years ago. All of it is now in code and reviewable.

Phase 3: Build the pipeline (Weeks 2-4, overlapping with phase 2)#

Create a Continuous Integration and Continuous Deployment pipeline:

1. On every commit:

   • Build the application (compile, package, create a container image)
   • Run unit tests
   • Run integration tests against a test database
   • Scan for dependency vulnerabilities
   • Scan for security issues in the code
   • If any step fails, the build fails and the commit does not proceed to deployment

2. If the build succeeds:

   • Deploy to a staging environment
   • Run smoke tests (is the app up? Can it hit the database?)
   • Wait for manual approval (optional, remove this later)
   • Deploy to production using a progressive strategy (canary or blue-green, see below)

Why this second: Because without infrastructure as code, you cannot deploy consistently. With it, you can.

Tools: GitHub Actions, GitLab CI, ArgoCD for Kubernetes. Pick one. They all work.

Phase 4: Make rollback testable (Week 4-5)#

Set up progressive deployment so if a release breaks, you catch it before it hits everyone.

Blue-green deployment: You have two identical production environments (blue and green). Traffic points to blue. You deploy to green. You test green. If it works, you switch traffic to green. If it breaks, you switch back to blue instantly.

Canary deployment: You deploy the new version to 5% of traffic while the old version handles 95%. You watch metrics. If the canary looks good, you shift more traffic (25%, 50%, 100%). If metrics degrade, you rollback instantly.

Either way: test the rollback. Actually run it. Monthly. Measure the time. Improve it. An untested rollback plan is a story, not a control.

Phase 5: Wire up observability (Week 5 onwards)#

Observability means you can answer "what is wrong" without guessing:

• Metrics — CPU, memory, request latency, error rate. Dashboards. Alerts when they go bad.
• Logs — Every request logged, errors marked, searchable. When something breaks, grep the logs.
• Traces — For complex systems, see the path a request took through the system. Did it hit the database? The cache? How long at each step?
• Dashboards — The on-call person's window into production. Is it normal or is something wrong?

Tools: Prometheus for metrics, ELK or Datadog for logs, Jaeger for traces. Or use managed services (CloudWatch, DataDog, New Relic) if you prefer not to operate the infrastructure.

Why last: Not because it is not important. Because the pipeline is useless without it. But it takes time to tune. Get the pipeline working first, then spend weeks getting observability right.

The order prevents reinvention#

If you try to do this in a different order, you get stuck:

• Start with CI/CD without IaC: Your pipeline deploys but to environments that diverge, so tests do not predict production behavior. You end up rewriting the pipeline when you finally do IaC.
• Do IaC without CI/CD: You have reproducible infrastructure but you are still deploying manually. Reproduce that 50 times and you will invent a pipeline.
• Skip progressive deployment: Your first pipeline works but breaks production because there is no safety rail. You add progressive deployment after an incident.
• Ignore observability: Your pipeline works and things deploy but when production breaks, nobody knows why. You spend a week adding observability in a panic.

The order above moves you forward without backtracking.

Success looks like this#

• Commits reach production multiple times a week
• A commit lands Friday afternoon, deploys automatically, nobody needs to watch
• A production issue appears in metrics before a customer notices
• You have rebuilt staging from code and it took an hour
• A rollback is a revert and takes 5 minutes
• Your team deploys features instead of fighting deployment infrastructure

Who does this#

You can do this with your team. Or we can do it with you. Either way the goal is the same: boring deploys that happen during working hours, infrastructure you can read and change, and the ability to ship without ceremony.

The first step is measuring your baseline. Do that this week. The numbers will tell you whether the work is worth doing.

(It always is. We have never met a team that measured their deploy frequency and did not want to improve it.)