What are the phases of the DevOps lifecycle, and how does a change actually flow through them from an engineer's laptop to a live user?

Picture an assembly line at a car factory, except the line doesn't stop at the loading dock — it continues all the way to sensors inside the car that report back to the factory floor when something goes wrong on the highway. Traditional software delivery stopped at 'shipped.' The DevOps lifecycle treats shipping as just the midpoint, because a change isn't actually validated until it's been observed behaving correctly with real traffic.

The lifecycle exists as a named set of phases because each one used to be a separate team's responsibility with a manual hand-off in between, and naming them explicitly makes it obvious where automation should replace a ticket queue. Continuous development covers planning (what are we building and why) and coding. Continuous testing means every commit is automatically exercised by unit, integration, and sometimes contract tests before a human ever looks at it. Continuous integration merges that code into a shared trunk frequently, catching merge conflicts and regressions in hours instead of at the end of a multi-week feature branch. Continuous deployment pushes the validated build to production, often progressively. Continuous monitoring watches real production behavior. Continuous feedback routes what monitoring found back to the humans planning the next change. Continuous operations is the ongoing work of keeping the whole loop healthy — patching, capacity planning, incident response.

Mechanically, this is implemented as a pipeline: a git push triggers a CI runner, which executes the test suite, builds an artifact (a container image, a compiled binary), and if every stage passes, hands that artifact to a CD system that deploys it, typically to a staging environment first and then production behind a canary or blue-green rollout. Monitoring tools (Prometheus, Datadog, CloudWatch) scrape metrics from the new version immediately, and alerting rules compare its error rate and latency against the previous version.

In production, the phase that separates mature teams from immature ones is continuous feedback: does an anomaly in monitoring actually change what gets planned next sprint, or does it just get acknowledged and forgotten? Teams that close this loop use their incident and metric data to prioritize reliability work, not just new features. The gotcha engineers miss: these phases aren't sequential stages you pass through once per release — they run continuously and in parallel across many changes at once, which is why a single service can have five different versions moving through five different phases of the lifecycle simultaneously at any given moment.