01
Step one: list the release in the order it happens
Start by writing every action from a merged change to a verified live release. Take a small customer portal: confirm the build passed, back up the database, apply migrations, deploy the new version, clear caches, then check the login page. Number each action and name its owner. Include the exact command or button used, not a description of it. If a step depends on a credential, note where it is stored rather than the secret itself. Keep sentences short and begin each with a verb. The aim is that someone unfamiliar with the project can perform the release without asking questions.
02
Step two: add checks and a way back
After each risky action, add a check with an observable result. After migrations, run a query that confirms the expected table change. After deployment, load the health page and confirm the version number matches. Then write the rollback beside the step, not in a separate document: restore the backup, redeploy the previous version, and note how long each takes. Add a decision point stating who can call a rollback and what failure triggers it, such as errors on login for more than five minutes. This prevents hesitation when pressure is high.
03
Step three: rehearse, then revise after each release
Run the document in a staging environment with someone who did not write it, and watch where they pause. Each pause marks a missing detail. Fix those gaps, then record the date, the person and the time the rehearsal took. After every real release, spend ten minutes noting what surprised the team and update the runbook the same day. For the portal example, this might add a step for warming the cache after a slow first page load. A short change log at the top shows readers that the instructions are current and trusted.