CI/CD & DevOps Practices Practice Question 9: Expand Contract Rollback
CI/CD & DevOps Practices · Test 1 · question 9 of 10
A team uses blue/green deployments. Version 2 of its service renames the database column cust_name to customer_name, and version 1 reads and writes only cust_name. Both environments share one database. The team's rule is that if version 2 misbehaves after cutover, it must be possible to switch the router straight back to version 1 without losing any customer data written in the meantime.
How should the team roll out the schema change?
Show answer and explanation
Answer:
For blue/green, Fowler's advice is to separate schema changes from application upgrades. First change the schema so it supports both the old and new versions, deploy that, and confirm it works; that gives a rollback point. Only then deploy the new version. This is the parallel change (expand/migrate/contract) pattern: expand the schema so both versions work, migrate the clients, and contract by dropping cust_name once nothing uses it. Throughout the cutover, version 1 can still run against the database, so switching back is immediate and loses no data (D).
Option A loses data. Restoring the backup throws away every write made after cutover, which the rule forbids.
Option B makes switching back slow and risky. Once cust_name is renamed, version 1 cannot run at all, so a router switch alone would fail. The team would have to run a down-migration during the incident, and any rows written by version 2 are caught up in the reverse change.
Option C drops the team's own rule. Rolling forward is a valid choice when rolling back is impossible, but here a compatible schema change keeps the faster, safer rollback available.
References: Blue Green Deployment (Martin Fowler); Parallel Change (martinfowler.com)