DevOps practices (blueprint)
Purpose: Deep, project-agnostic guides for core DevOps practices. Each practice describes its principles, implementation patterns, maturity progression, and lifecycle mapping.
Guide · Updated · Source
DevOps practices are the how of continuous delivery: they turn culture and goals from DEVOPS.md into repeatable workflows — automated pipelines, codified infrastructure, observable systems, and resilient response — so teams ship small batches safely and learn from production.
Non-goals: These blueprints do not mandate a single vendor or cloud; they emphasize patterns you can map to your stack. Product-specific SLAs, pipeline definitions, and environment names stay in repository documentation, not here.
Audience: Teams adopting DevOps; project-specific CI/CD and operations configuration stays in docs/development/ (see docs/development/CI-CD.md) and docs/operations/.
DevOps practices adoption path
How teams move from shared DevOps vocabulary through core practice guides to repeatable, governed delivery workflows.
- StartAlign on CALMS, Three Ways, and DORA baselines from the body of knowledge.
- Core steps (see walkthrough below)Harden CI/CD and IaC, then define SLOs and formalize incident response.
- OutcomeTurn culture and goals into traceable pipelines, codified infra, and resilient response.
- Note: CI/CD pipelinesPipeline stages, gates, and deployment strategies live in the CI/CD guide.
Process flow
Start
|
v
Core steps (see walkthrough below)
|
v
Outcome
Note: CI/CD pipelines| Practice | Guide | Focus |
|---|---|---|
| CI/CD pipelines | Continuous Integration & Continuous Delivery / Deployment (blueprint) | Continuous integration and delivery/deployment — pipeline design, stages, quality gates, deployment strategies, DORA-aligned metrics |
| Infrastructure as Code & GitOps | Infrastructure as Code & GitOps (blueprint) | Declarative infra, plan/apply workflows, pull vs push deploy, drift, secrets — Terraform-class tools and Argo CD / Flux |
| SRE and observability | SRE and observability (blueprint) | SLOs/SLIs/error budgets, logs/metrics/traces, alerting, chaos engineering, on-call, blameless postmortems |
| Incident management | Incident management & response (blueprint) | Severity, roles, comms templates, on-call, SEV1 flow, metrics (MTTA/MTTR), learning loops |
Suggested reading order for adoption: (1) align on DEVOPS.md vocabulary and DORA baselines; (2) harden Continuous Integration & Continuous Delivery / Deployment (blueprint) and Infrastructure as Code & GitOps (blueprint); (3) define SLOs and observability in SRE and observability (blueprint); (4) formalize response in Incident management & response (blueprint). Maturity is not linear — revisit earlier guides when failure modes change.
Core knowledge: DEVOPS.md — CALMS, Three Ways, DORA metrics, SRE, DevSecOps. For operational signals and SLO-driven delivery, start from SRE and observability (blueprint) alongside Continuous Integration & Continuous Delivery / Deployment (blueprint).
Bridge: DevOps ↔ SDLC ↔ PDLC bridge — how DevOps maps to delivery and product lifecycles.
Related: Tool choices and platform categories are summarized in DevOps tooling (blueprint). Chaos engineering and on-call depth live primarily under SRE and observability (blueprint); incident process detail under Incident management & response (blueprint).
Quick links: Continuous Integration & Continuous Delivery / Deployment (blueprint) · IaC & GitOps · SRE and observability (blueprint) · Incidents · DevOps body of knowledge
Keep project-specific DevOps configuration in docs/development/CI-CD.md and infrastructure documentation in docs/operations/, not in this file.