DevOps Lifecycle
DevOps is the cultural and technical movement to deliver software changes safely, quickly, and sustainably by removing walls between development and operations. It is not a job title alone, a tool chain alone, or "developers on call without support." It is shared ownership of production outcomes plus automation that makes frequent change low-risk.
Architecture and DevOps co-determine each other: deployable units, configuration strategy, observability, and rollback design are architectural decisions that enable (or block) continuous delivery.
| Pillar | Meaning | Smell if missing |
|---|---|---|
| Culture | Blame-aware learning; shared goals | Ticket tossing; hero culture |
| Automation | Repeatable build/test/deploy | Snowflake servers; manual release |
| Lean | Small batches; limit WIP; reduce waste | Huge releases; long queues |
| Measurement | DORA + SLOs + business metrics | Opinion-only debates |
| Sharing | Docs, on-call, postmortems | Tribal knowledge; bus factor 1 |
Use CALMS as a diagnostic: if you bought a CI product but culture still punishes failure, you have tooling without DevOps.
Continuous Integration
Every change integrates to mainline frequently with automated build and tests. Branch lifetimes stay short. Architecture must allow independent testing of modules.
Continuous Delivery
Every green mainline build is releasable. Release is a business decision. Requires DoD, env parity, and migration discipline.
Continuous Deployment
Every green build deploys to production automatically. Needs strong automated verification, progressive delivery, and fast rollback.
Continuous Learning
Postmortems, experiment results, and customer metrics feed the backlog — closing the SDLC loop.
| DORA metric | What it indicates |
|---|---|
| Deployment frequency | Batch size / throughput |
| Lead time for changes | Flow from commit to production |
| Change fail rate | Quality of verification & design |
| Time to restore service | Resilience & incident readiness |
Shift-left means moving quality, security, and operability earlier in the lifecycle — where fixes are cheaper:
- Security: threat modeling in design; SAST/dependency scans in CI; secrets hygiene.
- Testing: unit/contract tests with code; perf budgets on critical paths.
- Operability: design for logs/metrics/traces; define SLOs with features.
- Accessibility and privacy: treat as NFRs with acceptance checks.
best practice
A common loop: Plan → Code → Build → Test → Release → Deploy → Operate → Monitor → (feedback) Plan. Architecture decisions appear in every stage:
| Stage | Architecture concern |
|---|---|
| Plan | Enablers & NFRs on backlog |
| Code | Module boundaries; ports/adapters |
| Build/Test | Fitness functions; contract tests |
| Release/Deploy | Deployable topology; flags; migrations |
| Operate/Monitor | SLOs; failure domains; runbooks |
| 1 | stages: [build, test, harden, deploy] |
| 2 | build: [compile, unit] |
| 3 | test: [integration, contract] |
| 4 | harden: [sast, deps, smoke] |
| 5 | deploy: |
| 6 | strategy: canary |
| 7 | rollback: automatic_on_slo_burn |
Platform engineering provides internal developer platforms (IDPs): paved roads for CI/CD, observability, environments, and golden paths. Teams self-serve without filing tickets for every cluster detail.
- Why: reduce cognitive load; standardize security baselines; improve DORA metrics.
- How: treat the platform as a product with users (app teams), SLAs, and docs.
- Architecture link: platforms encode architectural standards (service templates, module layouts) as defaults — not only wiki pages.
note
| Requirement | DevOps response |
|---|---|
| Multiple deploys per week | CI/CD + small batches + flags |
| High availability SLOs | Progressive delivery + fast restore |
| Compliance with frequent change | Automated evidence generation |
| Many teams sharing infra | Platform engineering |
| Chronic release fear | Automation + blameless learning culture |
- Renaming ops to DevOps without changing incentives or automation.
- CI that is flaky — teams bypass it and lose the safety net.
- Continuous deployment into an unobservable system.
- Ignoring database migration and schema compatibility.
- Architecture that requires downtime for every release.
- Make mainline green and trusted — fix flaky tests first.
- Automate one painful release step per week until releases are boring.
- Add progressive delivery before increasing deploy frequency.
- Define SLOs for critical user journeys; alert on burn rate.
- Run blameless postmortems with action items in the backlog.
- Invest in a thin platform: CI templates, observability defaults, env provisioning.
Architecture enablement
Strangle monoliths into deployable modules; expand contract tests; eliminate shared-DB coupling before splitting teams.
Security enablement
Shift-left scans + secrets management + least privilege cloud roles as paved road.
| Anti-pattern | Replace with |
|---|---|
| Monthly release train only | Small batches + flags; trains optional for marketing |
| Separate QA after code complete | QA engineers embedded; automation in CI |
| Ops as ticket sink | Platform self-service + shared on-call |
| No rollback story | Backward-compatible deploys + tested rollback |
DevOps compresses build/test/deploy into automated pipelines and shortens feedback from operate → plan. Requirements and design still matter; they simply iterate with production evidence. Treat pipeline stages as executable gates from the SDLC discussion.
Integrate security into the same lifecycle: policy-as-code, image scanning, secret detection, and least-privilege runtime identities. Security gates should be automated and fast enough not to recreate a late Waterfall security phase.
Community
Get help on Slack, Discord or VIP
Stuck on a guide? Join the community and ask.