Challenges with Merging Alembic Migrations in Multi-Developer Environments

[santhiya111]

When multiple developers work on separate branches and introduce new migrations, they often share the same parent revision, leading to conflicts when the branches are merged.

This results in frequent interruptions, requiring manual intervention to resolve conflicts by either changing the parent revision or creating a merge migration. While Alembic allows for "merge" migrations, this process requires human synchronization, leading to collisions and delays in the development pipeline, especially in fast-growing projects with frequent migration changes.

Would anyone have suggestions or experience in handling this issue more efficiently? Any help or insights would be appreciated!

[vtgn]

Hi!

Personaly I prefer to create a unique alembic revision file for each delivered version of my software, using a revision id equal to my software version, and displayed in the name of the migration file.
So during the development process of a version of my software, I use a script that manages the version set in the rev-id value of the alembic revision command by using a snapshot one (ex. if the current version developed is 1.2.0, I use the 1.2.0_snapshot revision value).
Each developer modifying the DB schema must always generate a new migration file based on the official previous version one (i.e. the migration file with the 1.1.0 revision for example): so if there is already a 1.2.0_snapshot migration file, he must delete it, downgrade his DB on the 1.1.0 revision, and autogenerate a new one with the same 1.2.0_snapshot revision. Thus, the auto generated code is uptodate.
The only problem with this method, is to keep in the new generated 1.2.0_snapshot migration file the manual code of the previous developers that was in the 1.2.0_snapshot migration file that has been deleted. The solution is just to include the manual code of the current developed version directly in the script.py.mako file. Thus, each time a new revision is generated, all the manual code of all the developers will be always present.
So we manage the merges in the script.py.mako by git and by replacing the old 1.2.0_snapshot migration file by a new one. At the end of the development of the current version, we delete the 1.2.0_snapshot migration file version, and create an official one with the 1.2.0 revision. And at the beginning of the development of a new version of the software, we just have to delete from the script.py.mako the manual code of the previous version.
You can do a script to manage automatically the regeneration of the migration file for the current version, so it is easy for all the developers to do it: they just have to maintain manually the script.py.mako file and launch this script to update the current versioned migration file from the last official one.

I hope I was clear enough in my explanations. ;)

Regards.