DevOps & Delivery

1. Environments and config

The same code must run in development, staging and production — and behave *differently* in each (URLs, secrets, feature flags), without three codebases quietly diverging. This lesson covers environment design (what differs and what must not), configuration as injected, validated, secret-aware data, twelve-factor discipline, feature flags as controlled delivery, and the drift that accumulates when environments are snowflakes. The goal is one artefact, parameterised — so staging is a rehearsal of production, not a cousin of it.

2. Containers you can trust

Containers package an application with everything it needs to run, so "it works on my machine" stops being a factor. This lesson covers what containers actually are (isolated processes, not virtual machines), images and their layers, Dockerfiles written for cache, size and security, multi-stage builds, registries and image provenance, orchestrators in brief (what Kubernetes solves and costs), and the anti-patterns that make containers untrustworthy. The deliverable is an image you can rebuild a year from now and get the same thing.

3. Deploy and rollback

A deployment is a controlled experiment on production: the goal is not that changes *arrive*, but that they arrive *observably* and *reversibly*. This lesson covers deployment strategies (recreate, rolling, blue-green, canary), the one-command rollback that makes them all safe, databases in the deploy window (expand-contract under a release), environments of infrastructure, release management with versioning, and the progressive-delivery patterns that turn deploys from events into routine. If you cannot roll back in minutes, you are not deploying — you are gambling.

1. Monitoring that wakes you, logs that explain

A system you cannot observe is a system you do not operate: dashboards tell you what is happening, metrics tell you what is *about to* happen, logs tell you *why*, and alerts tell a human *when* — and the difference between a healthy on-call rotation and a miserable one is almost entirely whether those four things were designed. This lesson covers the golden signals, metrics and how to slice them, structured logging that answers questions, traces for the request that crosses services, alerting on symptoms with runbooks, and dashboards that serve decisions. Instrument first; opinions after.

2. Backups and schema changes

There are two kinds of companies: those who have lost data, and those who have not yet — and the difference is a backup that was *restored* to prove it, plus a migration discipline that never bets data on an untested script. This lesson covers backup strategy (what, how often, where, how long), restore drills as the only real test, point-in-time recovery, migration safety under load, and the deletion and retention rules that satisfy both engineers and auditors. A backup is a hypothesis; a restore is a fact.

3. Incidents and blameless reviews

Incidents are not anomalies to be prevented forever; they are the price of change — and the difference between teams that improve and teams that slowly rot is entirely what they do in and after the incident. This lesson covers response as a role-driven checklist (detect, mitigate, communicate), rollbacks and mitigations under pressure, post-incident reviews without blame and their systemic action items, error-budget policy as the connective tissue, and blamelessness as a *technical* strategy — because the incident you hide is the incident you repeat. The goal: every incident makes the system measurably harder to break the same way.