CHAPTER 12 / 13 · READ → DECIDE → BUILD
Ship a version you can recover from.
Rehearse configuration, rollout, smoke checks, and rollback.
Identify exactly what you are releasing
Record a commit or build identifier and a target environment. Check the hosting provider's current instructions for your framework and runtime. Confirm required environment-variable names, callback URLs, public origins, and database connectivity without putting secrets in the workbook. Keep preview and production data separate. Deploy the learning board to a test or preview environment before inviting real users.
Sequence code and data changes
If a release changes the schema, consider the period when old and new application versions may both run. An additive expansion can often precede new code; removal may need a later release. Backfills need checkpoints and validation. A code rollback cannot automatically reverse incompatible data changes. Document the boundary where recovery would require a forward fix or a restore instead of simply selecting an older build.
Verify the deployed system
A successful build proves that a build completed. Open the deployed URL, confirm the intended version, and repeat a small set of critical checks: page load, login if needed, task listing, one reversible synthetic claim, and a competing claim. Inspect persistence. Test the actual environment configuration. Record any failed or skipped check and stop promotion if a critical rule is unverified.
Rehearse recovery while it is calm
In your test environment, practise returning to a known-good version and check the app afterwards. If your provider has a preview promotion or rollback feature, read its current behavior rather than assuming it also restores data. Write who can perform recovery, when to trigger it, and how to confirm it worked. You can finish the lesson with an explicitly labeled tabletop rehearsal, but do not describe that as a real deployment.
SEE THE DIFFERENCE
A small example. A better decision.
The build log is green. Launch complete.
Build abc123 is served at the test URL. A synthetic user completed the claim flow, a second claim was rejected, and the previous version was successfully restored in the rehearsal environment.
The second report names evidence about the deployed behavior and recovery. Only write these claims when you performed the checks.
Your build steps
- Choose a host and follow its official deployment instructions for your stack.
- Deploy the reviewed version to a test environment, or explicitly label a tabletop rehearsal.
- Run the critical smoke checks and record the URL/version where applicable.
- Rehearse rollback and check the application and data after recovery.
FROM THE PROMPT LIBRARY
A useful brief for this step.
Create a release plan with rollback ↗Makes deployment a controlled sequence with recovery options.Build a CI quality gate ↗Stops known-broken changes from becoming release candidates.Validate deployment configuration ↗Catches missing variables and environment mismatches before promotion.All release & deployment promptsMAKE THE CALL
Think like the reviewer.
BUILD YOUR WORKBOOK
A release and recovery record
Use the lesson and your project evidence. Your workbook saves privately; keep credentials and private records out. The checks below assess completion of the exercise, not the correctness of an external app.
Before moving on
Loading your workbook…