We deploy the same main branch to staging first and production later, using Alembic for database changes. A migration that fails staging can block later revisions, and a migration for an unfinished feature can end up running in production when another feature ships. How do teams handle this without making every release depend on every feature?
How do you keep Alembic migrations from blocking unrelated releases?
Asked by
cedarspool
Answers
I’d treat migrations as shared, ordered changes to the database, not as independent feature files. Alembic can have multiple heads and later merge them, but that does not make it safe to skip a revision that a later migration depends on.
For a migration that has not been applied anywhere, correcting or removing it may be possible, but first check every environment and any migration history other people rely on. Once a revision has been applied to a shared database, leave its identity alone and add a new revision to repair the schema. Rewriting history at that point can leave environments disagreeing about what has run.
Good migration tests and a review gate help catch failures before staging. They reduce the chance of a bad revision getting there, though they cannot eliminate every deployment issue.
Reply to this answer
For the unreleased-feature case, make the schema change safe to deploy before the feature is turned on. Add the new column or table in a compatible way, keep the application working with both old and new schema, and use a feature flag or separate code rollout to control when users see the feature. Cleanup can come in a later migration after the old path is gone.
That means the migration may reach production before the feature, but it should not itself activate the feature or break the current application. If a change cannot be made compatible in stages, then it is a release coordination problem, and the team needs an explicit gate rather than assuming the migration can be skipped.
Reply to this answer
Isolated databases per change are useful for testing migrations without one developer's work contaminating another's staging test. They do not by themselves solve what gets deployed to production, though. Production still needs a coherent migration history.
I’d combine disposable test databases with checks that build a database from the production revision and apply the proposed changes. Keep staging representative, and have a clear forward-repair plan for a revision that has already run. Trying to make a later migration jump over a broken predecessor usually just hides the dependency instead of fixing it.
mildlyferal:
That distinction helps. Separate test databases catch collisions earlier, while deployment policy still has to decide which schema changes are safe to ship.
Reply to this answer
Add your answer
Answers are reviewed before publication.
tinylawyer:
So the key distinction is whether the revision has already been applied to a shared database, not just whether it reached the main branch?