3. Stage a release, verify it and roll back code

Objective & prerequisites

Use versioned artifacts and a controlled local activation step while preserving state. Prerequisites: Python functions, JSON, basic SQL, Git and the existing software/testing workshops. Extract the full kit and open a terminal in cloud-operations-kit. Python 3.10+ with its standard SQLite module is sufficient for the executed labs; no cloud account, credentials, package installation or network is needed. All data and prices are invented teaching fixtures. The runnable drills use new temporary folders and databases, never the website or hosting. These free companions retain existing course progress/access. Payments and public registration remain disabled.

python3 lab.py
python3 -m unittest discover -s tests -v

Understand the concept

A release should identify the exact artifact, compatible state schema, required configuration, acceptance checks and recovery action. Build once and promote the reviewed artifact rather than editing production files by hand. A checksum can identify expected bytes but is not an independent signature or security audit. This local drill validates a small release contract, checks its canonical-content hash, writes an immutable version file and atomically replaces a JSON pointer on the same filesystem. It is a filesystem demonstration, not a distributed rollout, health-probed deployment or guarantee against power-loss durability problems. Real traffic routing and schema migrations require a separate design.

Worked example

The drill activates v1, then compatible v2. A v3 artifact with an empty message fails the declared smoke check before activation, so v2 stays current. Rollback repoints to v1. A fictional learner-state file keeps the same hash throughout. The smoke check validates the contract only; it does not execute a web application or establish end-to-end production health. An incompatible schema version is refused rather than pretending old code can safely read new state.

from lab import release_drill
r=release_drill()
assert r=={"failed_release_kept_v2":True,"rolled_back_to":"v1","state_unchanged":True}

Try it yourself

Run release_drill. In a temporary practice directory, try a wrong hash, reuse a version name with changed content and propose schema_version 2. Write separate rollback steps for a code regression and a data-corruption incident. Never pass the live website folder to the teaching activation function. Predict the result first, keep the original fixture, and record the exact command and observed outcome from your practice copy.

Knowledge check

Does switching back to an older application version automatically make an incompatible database migration safe?

Evidence, mistakes & handover

State whether an activity was executed locally, reviewed as a design, or left unexecuted. A successful local drill does not verify a cloud provider, container, hosted pipeline or production recovery. Keep an owner, acceptance criteria, known failures and rollback/cleanup evidence with the work. The download includes source fixtures, runnable drills/tests, separate exercises and solutions, a runbook, a resource plan, an optional container/CI review pack and a capstone rubric. Credit the teaching baseline and your own contribution; no certification, commercial service or employment guarantee follows.

Authoritative reference

Read the official reference ↗

— primary/official reference for the mechanism. Lesson explanations and fictional cases are original. Provider details can differ; this lesson does not configure or provision an account. No production access, payment, public registration or live deployment is activated.