MODULE 12 OF 12 · RELEASE 3 · OUTLINE
Deployment & Production Operations
Shipping changes calmly, and undoing them faster than you shipped them.
This module is an outline. The plain-language explanation and the lab specification below are final. The full written lesson and its runnable lab repository are still being prepared, and enrolment is not open.
Theatres rehearse the fire drill when there is no fire. Not because they expect one, but because the middle of an emergency is the worst possible time to be reading instructions for the first time.
So what is this really about?
Releasing software is routine right up until it is not. The teams that stay calm are the ones who decided in advance what has to pass before a release goes out, and who have actually practised undoing one — including the database, which is the part everyone forgets.
QUICK CHECK
A release passes every check but breaks under real traffic. What matters most in the next ten minutes?
The words you will hear
- Pipeline
- The automatic checks a change must pass before it can go live.
- Gate
- A check with real authority to stop a release. A check that cannot block is decoration.
- Rollback
- Putting the previous version back, quickly and without losing data.
- Migration
- A change to the database shape. Additive ones let the old version keep working — which is what makes rollback possible.
By the end you will be able to
- Build checks that can genuinely stop a bad release.
- Keep secrets and settings out of your code.
- Practise undoing a release before you have to do it for real.
How it is put together
CI runs typecheck, tests, the evaluation baseline and the security corpus; any failure blocks the deploy. Configuration comes from the environment, secrets from a managed store, and neither is ever in the repository. Migrations are additive and deployed before the code that needs them, so the previous version keeps running and rollback stays possible.
Where you start
A project deployed by running a command on a laptop.
The lab
- Build the pipeline with every gate, including the evaluation and security suites.
- Move configuration to the environment and secrets to a managed store.
- Make migrations additive and deploy them ahead of the dependent code.
- Write and rehearse a rollback procedure, including the database.
- Write the runbook: deploy, roll back, rotate a secret, handle an outage.
What goes wrong, on purpose
The scenario. A deploy passes CI but causes errors in production that only appear under real traffic.
What should happen. Alerts fire within minutes, rollback restores the previous version without a destructive migration, and the runbook is followed rather than improvised.
How you prove it works
- A pipeline run proving each gate can block a release.
- A rehearsed rollback, timed, including the database step.
- A secret-scanning check over the repository history.
What you walk away with
A pipeline whose gates genuinely block, a rehearsed and timed rollback, and a runbook written before it was needed.