Phoenix application code and Ecto migration rollback: keeping schema and code in sync after schema changes

Goal: Ensure that after rolling back a migration, the deployed Phoenix application code remains compatible with the resulting database schema, avoiding missing columns or tables that the code expects.

Constraints: Ecto’s change/0 can automatically reverse only a subset of schema operations; dropping columns or tables loses data unless a compensating step is added, and execute/1 cannot be inverted automatically. The safety of a rollback also depends on whether the database supports transactional DDL and on the exact Ecto version in use.

Uncertainty: The project has not settled on whether to treat every migration as required to be reversible (using change/0 or explicit up/down) or to allow irreversible migrations and rely on manual restore procedures, and how to detect mismatches between code and schema after a rollback.

• Should the team enforce that all migrations be reversible via change/0 or explicit up/down, treating irreversible migrations as a policy violation?
• What automated checks can be added to CI to verify that the deployed Phoenix code matches the schema after a rollback?
• How should rollback be handled when a migration removes a column or table that is still referenced by the application code?