How a small team can release a change safely
A release plan for a database-backed website, including a rollback rehearsal.
Matrix IT ·
Make the release repeatable
Start from an identifiable Git revision. Run the tests and build once, then use the same package in staging and production. Configuration and secrets belong to the environment. Before deploying, record who approves the release and which check has to pass.
Plan database changes separately
To rename a column the app uses, one option is to add the new column while keeping the old code compatible. Copy the data, switch the app over, and remove the old column once deployed versions no longer need it. Rehearse with a test copy. Removing the old column first can leave the rolled-back app without the data it expects.
Try a real action
A 200 on the homepage says the server responds. Also try signing in, sending a test enquiry or performing an action that will not affect a real customer. Check the error log and an important external dependency. Say who gets the alert if the check fails.
Rehearse the rollback
Introduce a failure in staging and switch back to the previous package. Verify what data changed between releases and what a backup can restore. When the real release starts, have the previous version, tested steps and your stop condition ready.