How do you handle database schema migrations in an automated deployment pipeline?

Summary

Make every migration backward compatible with the code that is running (expand and contract), run migrations as a separate, controlled pipeline step before the new code rolls out (not on application start-up across many replicas), make them idempotent and reviewable, and keep destructive changes for a later release after nothing uses the old schema.

Longer Answer

Example of renaming a column: add the new column, deploy code that writes both and reads the old, backfill in batches, switch reads to the new column, stop writing the old, then drop it in a later release. Large table changes need online schema tools or batching to avoid locks. Rollbacks then mean deploying previous code, which still works with the expanded schema; never rely on "down" migrations in production for destructive changes.

Key Points

• Expand and contract.
• Separate migration step, run once.
• Backward compatible with running code.
• Destructive changes later; batch big changes.