DevOps Best Practices: A Non-Fluffy Checklist

There's no shortage of DevOps advice that amounts to "communicate more" and "embrace a culture of collaboration." True, but not actionable. This is a checklist of specific, concrete practices across the areas that actually determine whether a team ships reliably — CI/CD, infrastructure as code, observability, incident response, security, and the collaboration habits that make the rest of it stick.

Quick Answer

The practices that consistently separate teams that ship reliably from teams that don't: automated tests gating every merge, a single deployment pipeline used for every environment (not a different manual process for production), infrastructure defined as code and reviewed like application code, monitoring that alerts on leading indicators rather than only hard outages, a blameless post-incident review process that produces tracked follow-up actions, security checks integrated into the pipeline rather than bolted on at the end, and small, frequent changes over large, infrequent ones. None of these require exotic tooling — most require discipline about using the tooling you already have consistently.

Written by [Neil Millard](/about), a cloud and automation specialist with 20+ years' experience delivering infrastructure for organisations including Barclays, HMRC, Marks & Spencer, and AXA.

CI/CD

• Every merge to the main branch runs the same automated test suite — no "it's a small change, skip the tests" exceptions. Exceptions are how a "small change" becomes the incident.
• The same pipeline deploys to every environment. If staging is deployed one way and production another, you are not really testing the production deployment path — see what should every CI/CD pipeline include to catch bugs early for what a pipeline needs to actually catch problems before they reach users.
• Build once, promote the artifact. Build a single versioned artifact and promote that exact artifact through environments, rather than rebuilding from source at each stage — this is what makes "it passed in staging" a meaningful statement about what's running in production; see deployment vs release: what is the difference for why this distinction matters.
• Keep the pipeline fast. A pipeline developers wait ten minutes for gets bypassed under pressure; one that finishes in two or three doesn't. Cache dependencies and container layers rather than re-downloading them on every run.
• Small, frequent changes over large, infrequent releases. A change that touches one thing is fast to review, fast to test, and fast to roll back if it's wrong. Batching a sprint's worth of work into one release multiplies the blast radius of anything that goes wrong.

Infrastructure as Code

• All infrastructure changes go through version control and code review, no exceptions for "just this once, I'll fix it in the console." A console change that isn't reflected back into the IaC config is drift that will silently get reverted on the next apply, or worse, silently diverge from what the team believes is running.
• State (Terraform state, or equivalent) is stored remotely with locking, not on someone's laptop. A lost or corrupted local state file is one of the more painful ways to lose a day.
• Treat IaC changes like application code changes — plan/diff output reviewed in the pull request before merge, not applied directly from a developer's machine.
• Modules/roles are reused, not copy-pasted. Copy-pasted Terraform modules or Ansible roles are copy-pasted bugs waiting to diverge quietly across environments.

Observability

• Metrics, logs, and traces are treated as three different tools for three different questions — metrics tell you that something is wrong, logs tell you why, traces tell you where in a distributed call chain the time or error occurred. See monitoring tools in DevOps for how these map to actual tooling choices.
• Alerts are tuned to fire on leading indicators, not only on hard outages — rising error rate, growing queue depth, degrading latency — so the team finds out before customers do.
• Alert fatigue is actively managed. An alert that fires constantly and never means anything gets ignored, and that's how the one that matters gets missed too. Every alert should be actionable; if nobody would act on it at 3am, it shouldn't page anyone.
• Dashboards answer specific questions, not just display everything that can be measured. "Is the checkout flow healthy right now" is a better dashboard than a wall of every metric the service emits.

Incident Response

• A documented on-call rotation and escalation path exists before it's needed, not improvised during the first serious outage.
• Post-incident reviews are blameless and produce tracked follow-up actions. A review that ends with "let's be more careful" has produced nothing; a review that ends with a ticket to add a specific alert or fix a specific gap has.
• Runbooks exist for known failure modes and are kept close to the systems they describe, not buried in a wiki nobody remembers to update.
• Time to restore service is tracked as a metric, not just deployment frequency — a team that ships fast but recovers slowly from failure is not actually more reliable than one that ships more cautiously.

Security (Shift-Left)

• Dependency scanning runs in CI, catching known-vulnerable packages before merge, not in a quarterly audit.
• Secrets never live in source control. Use a secrets manager or vault, and scan the repository history for anything that leaked in before the scanning was added.
• Static analysis and basic security linting run alongside unit tests, as a normal part of the pipeline rather than a separate security-team gate that happens late and blocks release.
• Least-privilege access is the default for both infrastructure and CI credentials — a pipeline that can deploy to production should not also have blanket admin access to every other environment.

Culture and Collaboration

• Whoever writes the code can deploy it, without needing to hand off to a separate team — this is what actually shortens lead time for changes, one of the four DORA metrics.
• Documentation lives next to the code it describes (a README in the repo, not a separate wiki that drifts out of sync) so it gets updated in the same pull request as the change it documents.
• On-call and pipeline ownership rotate rather than concentrating in one or two people — a team where only one person can safely deploy or debug production is one person away from a very bad week.
• Retrospectives happen regularly and change something — a retrospective that produces the same three action items every sprint that never get done is theatre, not practice.

Where to Start

If none of this is in place yet, the highest-leverage starting point is almost always CI: automated tests gating merges, and a single pipeline used for every environment. Everything else — better observability, calmer incident response, security shift-left — is much easier to build on top of a working pipeline than to bolt onto a manual, ad hoc process. For a broader view of how these practices map to organisational maturity, see the DevOps maturity model.

If you want help figuring out which of these to prioritise for your team's actual constraints, that's exactly what an office-hours call is for.