How does code become production, and stay operable while it keeps changing?
Not a tour of CI tools, YAML or kubectl. The engineering question underneath: how do we reliably turn source into a running system, operate it safely, change it continuously, and recover when production behaves differently from our assumptions?
Where this sits
Cloud & Infrastructure owns what primitives exist. This domain owns building, releasing, deploying, operating and changing production on top of them.
theirs What infrastructure exists and how it is provisioned
ours How we build, release and operate on it
theirs How the service is implemented
ours How it becomes production and stays operable
theirs How to understand a running system
ours What an operator does with that under time pressure
theirs How software is attacked
ours Supply chain, secrets and production access as delivery concerns
Start here
Thirty-three modules
What makes production different from every environment you can reason about locally — real traffic, real data, real failure, real cost, and continuous change — and what DevOps actually means once it stops being a job title.
Plan, code, review, build, test, package, release, deploy, verify, operate, learn — each stage with its inputs, outputs, evidence and rollback story.
A commit is not history; it is a candidate for production state. Branching models, protected branches and required checks as delivery infrastructure rather than team preference.
CI as a feedback system, not a task runner: what to check, in what order, how to parallelise it, what to cache, and why a slow pipeline changes engineering behaviour.
Turning source into an artifact you can trust: reproducibility, pinned inputs, environment isolation, and being able to prove where a binary came from.
Build once, promote many. Immutable outputs, digests versus tags, registries, retention, and why rebuilding per environment quietly destroys your evidence.
The lifecycle from source to running process, layers and caching, what image size actually costs, and the process and signal model that decides whether deploys drop requests.
Staging is not production. Drift, parity, preview and ephemeral environments, and the limits of pre-production evidence — including why more environments is not more safety.
Artifact plus configuration equals a running service. What belongs in each, validating at startup rather than discovering at 3am, and treating config as a deployable with its own blast radius.
Credentials out of source and out of images: workload identity, secret managers, and rotation that applications actually survive.
Describing infrastructure so it can be reviewed, reproduced and changed safely — plans, state, drift, and the destructive changes a rename can hide.
Recreate, rolling, blue/green, canary, shadow and flags — each with how it works, what it risks, what it costs, and how you get back.
Blast radius as the organising idea: version coexistence, canary analysis against a baseline, rollback that is actually safe, and when rolling forward is the only option.
The change most likely to cause an outage and least likely to be rehearsed: expand/migrate/contract, backfills, locks, and why a migration and a deploy are one coupled event.
What orchestration problems exist, which abstractions answer them, and how to decide whether you need any of it — taught as one implementation, not as what production means.
Reconciliation as the core mental model, plus the runtime behaviours that produce most real incidents: scheduling, requests and limits, OOM kills, throttling and probes.
Config, volumes and stateful workloads — why a database is not a stateless API with a disk attached, and where the abstraction stops helping.
The operational half of the network: service discovery, DNS behaviour under change, certificate lifecycles, load balancer health and draining connections without dropping work.
Deployment is not release. Versioning, promotion, release manifests, change management and the audit trail that lets you answer "what changed" during an incident.
Who can touch production, with what privilege, for how long — and what to do about the emergency where someone genuinely must.
Using observability rather than building it: alerts that demand action, symptom-based paging, dashboards an operator can act on, and the cost of noise.
Detect, triage, mitigate, communicate, recover. Stopping user impact before understanding cause, and the roles that keep a severe incident coordinated.
Blameless but accountable learning: contributing factors over single root causes, and action items specific enough to change the system rather than the people.
What a service owes before it carries traffic — an owner, a runbook that encodes understanding, dashboards, alerts, a rollback plan and a tested recovery path.
What saturates first, how much headroom failure and deploys require, and cost as a first-class trade-off against reliability and performance.
Scaling on the signal that reflects the actual constraint, and the lag, cold starts, oscillation and downstream bottlenecks that make autoscaling a capacity tool rather than a capacity answer.
Backups you have restored, recovery objectives connected to real runbooks, region failover as an operational procedure, and the capacity question failover always raises.
Everything between a dependency and a running artifact is attack surface: pinning, scanning with context, signing, provenance and SBOMs.
Internal products that make safe delivery the easy path: golden paths, self-service with guardrails rather than gates, policy as code, and developer experience as an operational metric.
Reducing manual, repetitive, automatable work — and the trap of automating something you do not understand, which scales mistakes faster than it scales work.
The day-to-day of running databases, queues, caches and scheduled jobs: connection budgets, dead letters, hot keys, and why production time is always UTC.
Working from symptom to cause under time pressure, starting from the highest-signal question there is: what changed?
Prompts, models and tool definitions are deployable production inputs. Versioning, evaluation before rollout, canaries judged on quality and cost, and a kill switch that does not need a redeploy.
Reference
CI hides the build. Containers hide the process. Kubernetes hides scheduling. IaC hides cloud APIs. Deployment platforms hide rollout mechanics. Managed services hide infrastructure.
Use all of them. But when one fails, you are debugging the thing it hid — so know what it was doing on your behalf.