DevOps

10 units, 26 lessons and 48 questions on DevOps. Every question is scored on submit with an explanation. Free, and open without an account.

What is in it

Branching strategies, and which ones survive contact with a release.

Why long-lived branches hurt — A branch that lives for weeks accumulates conflicts nobody can review. Trunk-based development keeps branches short precisely so that merging stays boring.
Feature flags instead of branches — Merging unfinished work behind a flag keeps the branch short and makes the release a runtime decision rather than a merge.

What a pipeline is for, and how it earns or loses trust.

What CI is actually for — CI answers one question on every change: does main still work? Everything in the pipeline should serve that answer, and anything that does not belongs elsewhere.
Flaky tests — A test that fails at random teaches the team to re-run rather than to read. One flaky test damages a suite more than several missing ones.
Build once, promote the artifact — Build the artifact a single time and move that same artifact through environments. Rebuilding per environment means what you tested is not what you shipped.

Getting it out, and getting it back.

Rollback is the feature — The question is not whether a deploy will go wrong but how quickly it can be undone. A deploy you cannot reverse in minutes is a deploy you will be frightened of.
Blue-green and canary — Blue-green keeps two full environments and switches traffic. Canary sends a small share of traffic to the new version and watches. They answer different questions.
Health checks that mean something — A liveness check that returns 200 whatever happens is decoration. A readiness check should fail when the dependencies the service needs are unavailable.

Describing what should exist, rather than remembering what you clicked.

Declarative, not a script — You describe the desired end state and the tool works out the steps. A shell script describes steps and has no idea what already exists.
State and drift — The tool records what it believes it created. When somebody changes a resource by hand, reality and that record diverge — and the next apply may undo the fix or refuse to run.

Knowing what is happening, and knowing before the user tells you.

Logs, metrics, traces — Logs are events with detail. Metrics are numbers over time, cheap to keep. Traces follow one request across services. Each answers a question the others answer badly.
Averages hide the problem — Mean latency is the number that looks fine while the slowest few per cent of users suffer. Percentiles are what a person actually experiences.
Alert on symptoms — Alert on what the user feels — errors and latency — not on every internal number. An alert nobody acts on trains everyone to ignore alerts.

The hour it is broken, and the week after.

Stop the bleeding first — During an incident the goal is to restore service, not to understand it. Roll back, fail over, shed load — the diagnosis can wait for a calmer hour.
Blameless postmortems — Asking who did it produces careful people who hide mistakes. Asking how the system permitted it produces systems that do not permit it.

The credentials, and everything you did not write but ship anyway.

A committed secret is a leaked secret — Removing a key in the next commit does not remove it: it is in the history, in every clone and in every fork. The only fix is rotation.
Pin what you depend on — A floating tag means today's build is not yesterday's. Pinning to an exact version or digest makes builds reproducible and upgrades deliberate.
Least privilege, in practice — Deploy credentials that can do anything are the reason a small mistake becomes a large one. Scope them to what the job needs and nothing more.

A pipeline is a claim about whether a change is safe to ship. Most of the work is making that claim trustworthy.

Flaky tests, and why they are worse than failing ones — A test that fails at random teaches the team to ignore red. The cost is not the rerun; it is that a real failure now looks like noise. Quarantine and fix, or delete — leaving it is the one option with no upside.
Deployment is not release — Deploying puts code on the machine; releasing exposes it to users. Separating the two with a flag is what makes a rollback instant and a canary possible without a second environment.
Database changes under continuous delivery — Schema changes cannot be rolled back the way code can. Expand and contract — add the new shape, migrate, then remove the old — keeps every intermediate state deployable.

Service level objectives, error budgets and incident practice — the parts of SRE that change decisions rather than vocabulary.

SLIs, SLOs and the error budget — An SLI measures something a user experiences; an SLO is the target; the error budget is what remains. The budget is useful because it makes "ship faster" and "be more reliable" one conversation instead of two.
Incidents, and what a review is for — A blameless review looks for the conditions that made the failure likely, not the person who touched it last. Its output is a change to the system, not a promise to be careful.
Observability: logs, metrics and traces — Metrics say something is wrong; traces say where; logs say why. A system is observable when a new question can be answered without shipping new instrumentation.

Declared infrastructure, secrets, and knowing what is actually inside the artifact you ship.

State, drift and idempotence — Infrastructure as code is only true while the code is the source of truth. Manual changes create drift, and drift is discovered at the worst possible moment unless something checks continuously.
Secrets and build provenance — A secret in a repository is public the moment the repository is. Provenance answers a different question: which source and which builder produced this artifact, and can anyone verify it.