Prepare a software release with a database change
Rolling back code does not automatically fit a changed database. A complete test case shows what to check before switching versions and rolling back.
A software release sometimes changes both the application and the database. The rollback path must therefore account for more than the previous program version. Record which combination of code, configuration and data structure works together.
The hypothetical portal example below is a planned test case. It does not describe a change to a real customer database.
Test the rollback path against the same data state
The existing application V1 reads customer names from customer_name. The new application V2 is intended to read display_name instead. In the initially proposed sequence, the old column is removed. The new application then fails to start because configuration is missing.
Step | Database after the step | Outcome in the example |
|---|---|---|
Before the switch | Old name column exists | Existing application works |
After the planned change | Only the new name column exists | New application does not start because of configuration |
Redeploy only the old code | Still only the new name column | Old application cannot find the column it expects |
Redeploying old code does not revert the data structure. A rollback button in a deployment tool does not resolve this incompatibility by itself.
Plan a compatible transition
One possible alternative is a staged transition: retain the old column first and add the new one. Transfer existing values traceably. The team defines which field is authoritative and how changes remain consistent during the transition.
In a separate test environment, check both application versions against this intermediate state. Include changing a name and reading it correctly through both versions. A one-off copy is insufficient if subsequent values are written to only one field.
Only after the transition is confirmed and the old version is no longer needed as a rollback path should removal of the old field be planned. This changes again which older versions remain usable. That step needs its own decision.
Account for data arriving after the switch
An older backup may contain the previous structure. If new orders have since been accepted, they may be absent from that backup. Restoration must not silently discard those transactions. Which data arrives afterwards and how it is reconciled belongs in the recovery plan.
Depending on the change, a planned maintenance window or a targeted fix to the new version may be more appropriate. A staged transition is not a blanket promise of an uninterrupted update.
Record the rehearsal outcome
Document the tested version, configuration, data state and person who decides when something fails. In the test, follow an order through to confirmation in its destination, then rehearse the planned rollback path. Note which data is retained and what limitations apply.
This makes it possible to see before the production switch whether the planned rollback path actually fits the application and its data.
Sources
Read more
All articles
Cloud & Operations with ASES
Hosting, deployment, maintenance and support