DevOps Implementation Checklist 2026: 47 Steps to Production-Ready Pipelines

Use this checklist to audit your current DevOps implementation or plan a new one. Each item is a concrete, verifiable state — not a vague best practice.

Mark each item as Done ✅, Partial ⚠️, or Missing ❌ to get an honest picture of where you stand.

---

Section 1: Source Control & Branching

• All code lives in a Git repository (GitHub, GitLab, Bitbucket)
• Trunk-based development or short-lived feature branches (< 2 days)
• Branch protection on main/master: PRs required, direct pushes blocked
• PR review required before merge (minimum 1 approver)
• Commit messages follow a consistent convention (Conventional Commits recommended)
• Secrets and credentials are never committed (pre-commit hooks or secret scanning)

---

Section 2: CI — Continuous Integration

• Every PR triggers an automated test run
• Tests run in under 10 minutes (if longer, developers skip them)
• Test suite includes unit tests (> 60% code coverage for critical paths)
• Test suite includes integration tests against real dependencies
• Build fails if any test fails — no manual overrides
• Linting and static analysis run on every PR
• Security scanning (SAST) runs on every PR (Snyk, Semgrep, or similar)
• Dependency vulnerability scanning (npm audit, Safety, Dependabot)

---

Section 3: CD — Continuous Deployment

• Deployment to staging is fully automated on merge to main
• Deployment to production requires one-click approval OR is fully automated with gates
• Deployments are containerised (Docker)
• Container images are tagged with Git SHA (not latest)
• Container images are scanned for vulnerabilities before deployment
• Rollback is automated: one command or one button to revert
• Blue/green or canary deployment strategy for zero-downtime releases
• Feature flags available for gradual rollouts (LaunchDarkly, Unleash, or custom)
• Deployment notifications sent to Slack or equivalent

---

Section 4: Infrastructure as Code

• All cloud resources defined in code (Terraform, Pulumi, or CloudFormation)
• IaC stored in version-controlled repository
• Terraform state stored remotely (S3 + DynamoDB, Terraform Cloud, or similar)
• terraform plan output reviewed in PR before apply
• IaC linting and validation (tflint, checkov) runs in CI
• No manual console changes — all infra changes go through IaC PRs
• Separate Terraform workspaces or configurations per environment (dev/staging/prod)
• Secrets managed via Vault, AWS Secrets Manager, or equivalent (not hardcoded)

---

Section 5: Containerisation & Orchestration

• Applications containerised with Docker
• Dockerfiles use pinned base image versions (not latest)
• Multi-stage builds used to keep image sizes small
• Container runtime chosen: ECS, App Service, Cloud Run, or Kubernetes
• Resource limits (CPU, memory) set on all containers
• Readiness and liveness probes configured
• If Kubernetes: namespaces, RBAC, and network policies defined
• Container registry images scanned for CVEs (Trivy, Snyk, ECR scanning)

---

Section 6: Observability

• Metrics collected for all production services (Prometheus, Datadog, CloudWatch)
• Dashboards for error rate, latency (p50/p95/p99), and throughput
• Deployment markers on dashboards (correlate deploys with metric changes)
• Structured logging (JSON) for all services
• Log aggregation in place (CloudWatch Logs, Loki, Datadog, ELK)
• Distributed tracing for multi-service requests (Jaeger, Tempo, X-Ray)
• Uptime monitoring and synthetic checks (Uptime Robot, Checkly, or similar)
• Alert rules set for error rate spikes, latency regressions, and disk/memory pressure

---

Section 7: Security (DevSecOps)

• SAST (static analysis) in CI pipeline
• DAST (dynamic analysis) run against staging regularly
• Container image vulnerability scanning in CI
• Secrets manager in use — no secrets in environment variables or config files
• IAM roles follow least-privilege principle
• Network segmentation: services communicate only with required peers
• Compliance-as-code checks (SOC 2, HIPAA, PCI) automated where applicable

---

Section 8: Incident Response

• On-call rotation defined and documented
• Alert routing to on-call engineer (PagerDuty, OpsGenie, or Slack)
• Runbooks for top 5 most common incidents written and accessible
• Rollback procedure documented and tested
• Post-mortem process defined (blameless, focused on system fixes)
• MTTR tracked and reviewed monthly

---

Scoring Your DevOps Implementation

Count your ✅ items:

Score	State
40–47	Production-ready DevOps. Focus on refinement.
28–39	Solid foundation. Address the ❌ gaps systematically.
15–27	Partial implementation. CI/CD and IaC are the priority gaps.
0–14	Early stage. Start with Section 1 and 2.

---

What to Do With Your Gaps

Prioritise gaps in this order:

1. Source control basics (Section 1) — everything else depends on this
2. CI/CD pipelines (Sections 2–3) — highest ROI
3. IaC (Section 4) — prevents drift and enables reliable environment recreation
4. Observability (Section 6) — you can't improve what you can't see
5. Security (Section 7) — especially if you're handling customer data
6. Incident response (Section 8) — before you go to production with new pipelines

Need help closing the gaps? Ortem Technologies runs structured DevOps implementation engagements — a 2-week audit followed by a 4–6 week implementation sprint. We also offer DevOps as a Service retainers for teams that want an embedded engineer who owns the checklist ongoing.

Book a free DevOps audit → | How to Implement DevOps →