Guide G0 · DevOps path
DevOps Fundamentals
Why DevOps exists, from waterfall to agile to continuous delivery; the CALMS framework and the Three Ways; the DevOps lifecycle; CI, CD, and CT; IaC and configuration management; feedback loops; the roles; and how success is measured.
Start here
The mental model
Picture a restaurant where the chefs (developers) cook a dish, pass it through a small window to the waiters (operations), and never see what happens next. The chefs are rewarded for new dishes; the waiters are blamed when customers get sick. So chefs push out more dishes, waiters resist anything new, and customers wait. That's software delivery before DevOps: DEVELOPMENT wants change, OPERATIONS wants stability, and a wall sits between them.
DevOps removes the wall. The same team owns a service from idea to production and gets fast feedback from real users and real systems. Automation makes changes small, frequent, and safe, so speed and stability stop being enemies. Every course on this site is one piece of making that possible.
Go deeper
How it works inside
01From waterfall to continuous delivery
The SDLC (software development life cycle) is the sequence every change goes through: requirements, design, build, test, release, operate. WATERFALL does each phase once for the whole project, which means months between writing code and learning whether it works in production. AGILE shortened the development loop to two-week sprints, but often left a slow, manual 'release to ops' at the end.
DevOps extends agility all the way to production: CONTINUOUS INTEGRATION (merge small changes to main many times a day, each verified by automated build and tests), CONTINUOUS DELIVERY (every change is always releasable, and deploying is a button), and CONTINUOUS DEPLOYMENT (every change that passes the pipeline goes to production automatically). CONTINUOUS TESTING (the CT in CI/CD/CT) runs automated tests at every stage rather than in a phase at the end.
02The DevOps lifecycle
Drawn as an infinity loop because it never ends: PLAN (backlog, design), CODE (Git), BUILD (compile, package, container image), TEST (automated tests, security scans), RELEASE (versioned artifact in a registry), DEPLOY (to environments, ideally via GitOps), OPERATE (run, scale, patch), MONITOR (metrics, logs, traces, SLOs), and FEEDBACK back into PLAN. The speed of that loop is the speed at which a company learns.
03CALMS and the Three Ways
CALMS is a checklist for whether an organisation is really doing DevOps. CULTURE: shared ownership, blameless learning (SRE course, postmortems). AUTOMATION: builds, tests, infrastructure, deployments. LEAN: small batches, limit work in progress, remove waiting. MEASUREMENT: DORA metrics, SLOs, feedback from production. SHARING: knowledge, tools, and responsibility across teams.
The THREE WAYS (from 'The Phoenix Project' and 'The DevOps Handbook'): 1. FLOW: make work move fast from left (dev) to right (production) with small batches and automation. 2. FEEDBACK: amplify signals from right to left (monitoring, alerts, tests) so problems are found early. 3. CONTINUAL LEARNING: experiment, learn from failures, practise (game days, chaos engineering).
04Everything as code
INFRASTRUCTURE AS CODE (Terraform): servers, networks, and databases are declared in files, reviewed, versioned, and applied by tools. CONFIGURATION MANAGEMENT (Ansible): what's installed and configured inside machines, as code. PIPELINES AS CODE (Jenkinsfile, GitHub Actions YAML). POLICY AS CODE (Kyverno, OPA). GITOPS: the desired state of whole environments lives in Git. The common idea: if it isn't in version control, it isn't reproducible, reviewable, or recoverable.
05Measuring DevOps
The DORA research found four metrics that predict software delivery performance: DEPLOYMENT FREQUENCY, LEAD TIME FOR CHANGES, CHANGE FAILURE RATE, and FAILED DEPLOYMENT RECOVERY TIME, plus RELIABILITY. Elite teams deploy on demand, with lead times under a day and low failure rates, which shows speed and stability improve together (Platform Engineering course, Mission 2.4).
Do it
Hands-on lab
- 1
Map a value stream
Pick a real or imagined change ('add a discount code field at checkout') and write down every step from idea to production, with how long each step WORKS vs WAITS. Most teams discover that waiting (for reviews, environments, approvals, a release window) dwarfs working time. Those waits are what DevOps practices and every course here remove.
value-stream.mdwhole filemarkdown | Step | Work time | Wait time | Removed by | |------------------------------|-----------|-----------|-------------------------------------| | Write code + tests | 4 h | – | — | | Code review | 30 min | 1 day | small PRs, CODEOWNERS (Git) | | Build + test on CI | 12 min | – | caching, parallel jobs (CI/CD) | | Request a test environment | 10 min | 3 days | preview envs, GitOps (Platform) | | Manual QA | 2 h | 2 days | automated tests in pipeline | | Change approval board | 15 min | 5 days | policy as code, canary (GitOps) | | Deploy on release night | 1 h | 6 days | continuous delivery | | **Total** | **~8 h** | **~17 d** | lead time 17 days → target < 1 day |
3am practice
Failure drills
Each drill is a real failure mode. Read the scenario and the output, decide what's wrong, then reveal the diagnosis.
Drill #1
The 'DevOps team' that became a wall
A company renames its ops team 'DevOps' and routes every deploy, pipeline change, and environment request to it through tickets.
Decide
DevOps roles you'll see in job descriptions
| Role | Focus | Typical tools | Where to learn it here |
|---|---|---|---|
| DevOps Engineer | CI/CD, automation, infrastructure, deployments | Git, Jenkins/GitHub Actions, Docker, Kubernetes, Terraform | CI/CD, Docker, Kubernetes, Terraform |
| Cloud Engineer | Designing and running cloud infrastructure | AWS/Azure/GCP, Terraform, networking, IAM | AWS, Networking, Terraform |
| Site Reliability Engineer (SRE) | Reliability of production via engineering: SLOs, incidents, capacity | Prometheus, Grafana, OpenTelemetry, on-call tools | Observability, SRE, Stateful Systems |
| Platform Engineer | Internal developer platform, golden paths, self-service | Kubernetes, Backstage, Crossplane, Argo CD | Platform Engineering, GitOps |
| Release / Build Engineer | Build systems, versioning, release process, artifacts | Maven/Gradle, Artifactory/Nexus, CI | CI/CD (build systems, artifacts) |
| Infrastructure Engineer | Servers, networks, storage, often on-prem + cloud | Linux, Ansible, networking, virtualisation | Linux, Networking, GitOps (Ansible) |
| DevSecOps Engineer | Security built into the pipeline and platform | SAST, SCA, Trivy, Cosign, Kyverno, secret managers | DevSecOps, Platform (Kyverno) |
The bigger picture
Connects to
Prove it
Interview questions
What is DevOps?
Continuous delivery vs continuous deployment?
Explain CALMS.