Database Migrations
The change most likely to cause an outage and least likely to be rehearsed: expand/migrate/contract, backfills, locks, and why a migration and a deploy are one coupled event.
Five distinct risks hide under the word "migration", and every one of them scales with data you do not have in staging.
The pattern that makes schema change safe: add the new shape, move to it, and only remove the old shape in a later deploy.
The techniques that let a schema change land while the service keeps serving — and the engine-specific rules that decide which ones are available to you.
Schema and code version separately but must be compatible continuously, which makes every schema change a two-artifact rollout with a compatibility window.
Moving or computing data across every existing row is a long-running production write workload, and it needs the properties of a job rather than of a migration.
Dropping, renaming, truncating and narrowing are the only changes with no rollback — and during a rolling deploy they break the instances that have not been replaced yet.