DevOps readiness: a checklist before you invest

The clearest signal is what the team believes the tool will do. If the expectation is that a CI/CD platform, a container orchestrator or an observability suite will create discipline the team does not currently have, the purchase will disappoint — these tools automate existing discipline; they do not manufacture it. A pipeline takes whatever enters it and moves it faster, including bad code, untested changes and configuration drift.

Other signs are easy to spot once you look: deployments that depend on one person being available; a staging environment nobody trusts because it differs from production in ways nobody has written down; release notes assembled by memory; and rollbacks that mean "call the person who deployed it." None of these are tooling gaps. They are practice gaps, and tools bought to cover them tend to become expensive shelfware with a login page.

The good news is that readiness is cheap to assess and mostly free to start fixing. The checklist below is the same one we work through before recommending any DevOps or DevSecOps investment.

Three foundations sit underneath everything else. Without them, automation amplifies chaos rather than removing it.

Version control discipline

Everything needed to build and run the system lives in version control: code, obviously, but also configuration, database migration scripts and infrastructure definitions. The test is whether a competent engineer who joined yesterday can check out the repository and, following the readme, build the system. If tribal knowledge or files on someone's machine are required, start here. Nothing downstream works until this is true.

Environment parity

Development, staging and production should differ in scale and data, not in structure. When staging runs different versions, different settings or different services than production, "it worked in staging" becomes a meaningless statement and every deployment is a first deployment. Parity does not require expensive tooling — it requires deciding that configuration is code and treating differences as defects.

Basic automated testing

Not comprehensive coverage — a floor. A suite that runs the critical paths, completes in minutes, and is actually heeded when it fails. A pipeline with no tests is a faster way to deploy untested code; a pipeline whose tests everyone ignores is worse than none, because it teaches the team that red signals are normal.

Work through each area and mark it honestly: in place, partial, or absent. "Partial" almost always means the practice exists for some projects or some people — which in operational terms is absent at the moments that matter.

Source control

• All code, configuration and database changes live in version control.
• A branching convention exists and is actually followed.
• Changes are reviewed by a second person before merging.
• No credentials or secrets are committed anywhere in history.

CI/CD

• Every merge triggers an automated build and test run.
• Deployments are repeatable scripts, not documented manual steps.
• A deployment can be rolled back in minutes, and rollbacks have been rehearsed.
• Whoever merges code can see whether it deployed successfully.

Environments

• A staging environment exists and is structurally identical to production.
• Infrastructure changes go through the same review process as code changes.
• Spinning up a new environment does not require anyone's personal machine or memory.

Observability

• Logs are centralised and searchable, not SSH-into-a-box archaeology.
• Someone is alerted when the system is down — before a customer reports it.
• You can answer "what changed?" about production for any given hour.

Incident response

• There is a named owner for production incidents at any given time.
• Incidents end with a written review of causes, not just a fix.
• Runbooks exist for the failures that have happened more than once.

Most DevOps waste comes not from buying the wrong tool but from buying the right tool before its prerequisites exist. Three patterns recur.

1. Observability platforms before instrumentation. A monitoring suite ingests what your applications emit. If nothing emits structured logs, metrics or traces, the platform displays expensive emptiness. Instrument the application first; the platform decision then makes itself.
2. Elaborate pipelines for a monolith that ships monthly. A build-test-deploy pipeline for a single application is a week's work and pays for itself immediately. A multi-stage, multi-environment, canary-releasing deployment system for the same application is a hobby project consuming the engineers it was meant to free.
3. Kubernetes before containers. An orchestrator solves the problem of running many containerised services across many machines. A team running two services on three servers has a scheduling problem the size of a spreadsheet and will inherit an operations burden the size of a part-time hire.

In each case the remedy is the same: adopt the practice first in its simplest form, and let genuine pain — not conference talks — tell you when to industrialise it.

DevOps advice is mostly written by and for organisations with hundreds of engineers. Copied wholesale onto a team of eight, it produces ceremony without benefit. Size the investment to two numbers: how many people build the system, and how often you release.

• Small team, weekly-or-slower releases. Version control discipline, one straightforward pipeline, a real staging environment, basic alerting. This is a modest, mostly one-time effort with outsized returns — and it is where most small teams should stop for now.
• Growing team, daily releases. Add infrastructure-as-code, automated rollback, structured logging and an on-call rotation. Reliability engineering starts earning its keep because the cost of a bad deploy now compounds across customers every day.
• Multiple teams, continuous delivery. Container orchestration, progressive delivery, full observability and a platform mindset become justified — because coordination, not tooling, is now the bottleneck.

The expensive version of each tier rarely fixes the problems of the tier below. When in doubt, invest in the practice before the platform, and revisit the stack each time team size or release cadence doubles.

A realistic first DevOps improvement effort — for a team starting from the foundations — has a finish line, and it is not a transformed organisation. It is a small set of unglamorous capabilities that work without heroics.

• Every change to the main application goes through the pipeline: build, test, deploy — with no manual steps and no exceptions negotiated.
• Staging matches production closely enough that a failed staging deploy is trusted as a real signal.
• A failed production deploy is rolled back in minutes by whoever is on hand, using a rehearsed procedure.
• When the system is down, an alert reaches a named person before a customer email does.
• The team can state its deployment frequency, failure rate and time-to-recover from data, not impression.

That is a full 90 days of honest work for most teams, and it is worth more than any tool. It also produces exactly the evidence needed to decide what — if anything — to build or buy next, which is the point: the second phase of a DevOps journey should be chosen from evidence, not aspiration.