The DevOps lifecycle, from commit to production
The DevOps lifecycle runs plan, code, build, test, release, deploy, operate and monitor. Here is what to automate at each stage and how rollbacks and observability close the loop.
The DevOps lifecycle is a loop of eight stages: plan, code, build, test, release, deploy, operate and monitor. Each stage has a job that a machine can do more reliably than a person, and the goal is to make a change travel from a commit to production in small, boring, reversible steps. This guide walks the loop stage by stage and says what belongs in automation at each one.
The loop at a glance
- 01Plansmall work items
- 02Codebranch and pull request
- 03Buildone artifact, versioned
- 04Testcheapest checks first
- 05Releaseexpose to users
- 06Deployroll out the artifact
- 07Operatescale, patch, back up
- 08Monitorfeeds the next plan
What you learn while monitoring production feeds the next round of planning. A team that stops at "deploy" has a pipeline, not a lifecycle.
What to automate at each stage
| Stage | Automate | Human judgment |
|---|---|---|
| Plan | Link every change to a work item | Scope and priority |
| Code | Format, lint, type check, secret scan | Design and review |
| Build and test | One-command build, layered tests | Which journeys are critical |
| Release and deploy | Scripted rollout, feature flags | When to expose to users |
| Operate and monitor | Scaling, backups, alerts | What counts as healthy |
Plan and code
Planning is mostly human work, but a little structure pays off. Keep work items small enough to finish in a few days, and link every change to one, so you can answer "why did this ship?" months later.
For code, the decision that shapes everything downstream is your branching strategy.
| Strategy | How it works | Suits |
|---|---|---|
| Trunk-based | Small merges to main, often daily, unfinished work behind flags | Teams with strong automated tests |
| Short-lived branches | One branch per change, merged by pull request in a day or two | Most product teams |
Pull requests are the first automation gate. Require a passing build, one human review and a linked work item before merge. Add checks that run in seconds so reviewers can focus on design and correctness.
Build and test
A build should be a single command that produces the same artifact every time. Pin dependencies, build in a clean environment, and version the output so you can always tell what is running in production.
Packaging the application as a container image with Docker is the usual way to get that repeatability. The image that passed your tests is the same image that runs in staging and production, so "it worked on my machine" stops being an excuse.
Testing then runs in layers, cheapest first:
- Unit tests, which run in seconds and fail fast.
- Integration and API tests against real dependencies such as a database.
- A small set of end-to-end tests for the critical user journeys.
- Security scans of dependencies and images.
Release and deploy
CI/CD is the machinery that joins these stages. Continuous integration builds and tests every change. Continuous delivery keeps the main branch always releasable. Continuous deployment goes one step further and ships every passing change automatically. Many teams stop at delivery and keep a human approval before production, which is a legitimate choice for regulated systems.
A deploy puts new code on servers. A release exposes it to users. Feature flags let you deploy on Tuesday and release on Thursday, which makes deploys low-drama and releases deliberate.
Pick a rollout strategy that matches your risk:
| Strategy | How it works | Rollback |
|---|---|---|
| Rolling update | Replace instances gradually | Roll forward or redeploy previous |
| Blue/green | Run old and new side by side, then switch traffic | Switch traffic back |
| Canary | Send a small share of traffic, watch, then widen | Send the share back |
Infrastructure as code and orchestration
Servers, networks, databases and permissions should be described in files, not clicked into a console. Infrastructure as code puts environments under version control and review, so staging and production can be built from the same definition and a change to either shows up in a pull request. Terraform is a widely used tool for this on AWS, Azure and other clouds.
When you run many containers, an orchestrator such as Kubernetes schedules them, restarts failed ones, scales them and handles rolling updates. It also adds real operational weight.
Operate and monitor
Operating means running the system day to day: scaling, patching, backups and access control. Automate what repeats.
Monitoring is how you find out whether a release is healthy. Observability rests on three kinds of signal:
| Signal | Answers | Example |
|---|---|---|
| Metrics | Is something trending wrong? | Error rate, latency |
| Logs | What exactly happened? | One failed payment call |
| Traces | Where did this request spend time? | A request across services |
Alert on symptoms users feel, like failed checkouts or slow pages, not on every CPU spike. An alert that pages someone must be actionable.
Rollbacks
Plan the way back before you ship. The fastest rollback is redeploying the previous known-good artifact, which is only possible if you keep versioned images and deploy by version, not by "latest". Roll back first, investigate second.
Database migrations are the hard part. Write them to be backward compatible: add a column before using it, and remove it only after no code reads it. Code can then roll back without data rolling back.
Before any release, check:
- The artifact is versioned and the previous version is still available
- Migrations are backward compatible with the running code
- A feature flag or canary limits who sees the change first
- Alerts exist for symptoms users would feel
- Someone knows the rollback steps and can run them
How this looks at Techdome
Our DevOps and cloud work covers automated releases and infrastructure on AWS and Azure. The delivery stack we use on projects is Docker, Kubernetes, Terraform and GitHub Actions. We are an AWS Partner Network member and part of the Microsoft Startup Program at level 4.
The telehealth platform for the GLP-1 space (A US & UK Telehealth Platform) ran on AWS HIPAA infrastructure with Docker in its stack. For infrastructure at larger scale, we ran a long-term cloud infrastructure, Kubernetes modernization and site reliability engineering retainer for an enterprise cloud and managed services provider, which lasted 11+ months (An Enterprise Cloud Platform & Managed Services Provider).
Takeaways
- Treat the lifecycle as a loop: monitoring feeds the next plan.
- Make every stage automated and boring: pull request checks, one-command builds, layered tests, scripted deploys.
- Separate deploying from releasing, and use feature flags and canaries to lower risk.
- Define infrastructure in code and version your artifacts so rollback is a redeploy.
- Alert on user-facing symptoms, and plan rollbacks and backward-compatible migrations before you need them.
Have a project like this? Talk to our engineers.
