Blue-green deploys with schema migrations

WHAT THIS TESTS: Whether you grasp that blue-green deployment cleanly swaps stateless compute but cannot simply duplicate shared state, making schema changes the central risk.

A GOOD ANSWER COVERS: Blue and green normally share one database, so during the cutover window both application versions may read and write the same schema. A schema change that the old version cannot tolerate will break blue while it is still live, and it also blocks rollback because reverting the app would leave it pointing at a migrated schema. The fix is expand-and-contract, also called the parallel-change pattern. Expand: add new columns or tables that are additive and nullable, never removing or renaming yet. Deploy code that dual-writes to both old and new shapes and backfill historical rows. Migrate reads to the new shape once it is fully populated. Only after the old version is fully decommissioned do you contract, dropping the obsolete columns in a later, separate deploy.

COMMON WRONG ANSWERS: Running a destructive ALTER that drops or renames a column in one shot, assuming you can duplicate the database per color, or coupling the schema change to the same deploy as the code that needs it.

LIKELY FOLLOW-UPS: How do you keep dual-writes consistent? How do you backfill a huge table without locking it? How does this affect rollback safety? What if blue and green need genuinely different schemas?

ONE CONCRETE EXAMPLE: You must rename a column full_name into first_name and last_name. Instead of renaming, you add the two new nullable columns (expand), deploy code that writes both the old and new fields, backfill existing rows in batches, then ship a version that reads only the new columns. Throughout, both old and new app versions function because the old column still exists, so rollback stays safe. Weeks later, after the old version is gone, a separate migration drops full_name (contract).