跨Git仓库用Alembic管理单数据库多Base/分支可行吗？

Alembic的原生限制与可行变通 #

Alembic的迁移体系本质依赖本地的alembic.ini配置文件和env.py脚本，所有迁移文件必须与这些文件处于同一仓库层级——因为env.py需要加载对应的SQLAlchemy Base类来生成和执行迁移，跨Git仓库的Base类无法直接被Alembic的本地实例识别，原生不支持跨仓管理多Base/分支。但可以通过以下变通方式适配你的场景：

• 集中式迁移仓库+依赖安装：
  保留一个中央迁移仓库，将各应用的ORM包作为Python依赖安装到这个仓库的环境中。在env.py里导入所有相关的Base（中央库的基础Base+各应用的业务Base），这样Alembic可以扫描到所有表结构（包括跨应用的外键约束）。
  缺点：各应用的ORM变更需要先发布包，再更新中央迁移仓库的依赖，迁移文件仍需集中提交到中央仓，分布式团队协作的灵活性会打折扣。

• 分支迁移+显式依赖声明：
  用Alembic的分支功能，将中央库基础表的迁移作为主分支，各应用的表迁移作为子分支。在应用的迁移脚本中，通过depends_on参数显式声明依赖中央库的基础迁移版本。但所有迁移文件仍需集中在同一仓库，否则Alembic无法完整追踪版本线。

更适配分布式场景的替代工具 #

如果Alembic的变通方案不符合你的分布式架构诉求，可以考虑以下工具：

Flyway #

Flyway通过基于文件名的版本号机制管理迁移，支持模块化拆分迁移脚本：

• 可以将中央库的基础表迁移、各应用的业务表迁移放在不同目录，甚至通过Git子模块引用其他仓库的迁移脚本。
• 只要给不同模块的迁移文件分配不冲突的版本号（比如用前缀区分：V1_CENTRAL__init_tables.sql、V1_APP_A__user_features.sql），Flyway就能按版本顺序执行所有迁移，自动处理外键约束。

Liquibase #

Liquibase的changelog体系天然支持模块化：

• 中央库可以维护一个基础changelog，各应用的changelog通过include或includeAll语句引用基础changelog，同时维护自身的业务表迁移。
• 可以将各应用的changelog打包成JAR包或通过Git子模块引入，统一执行组合后的完整changelog来管理单数据库Schema。

自定义迁移框架（基于SQLAlchemy） #

如果需要完全自定义，可以基于SQLAlchemy的元数据对比能力，开发自己的迁移脚本：

• 每个应用维护自身的迁移逻辑和版本追踪表，中央脚本按预设顺序执行各应用的迁移，确保外键依赖的表先被创建。
• 缺点：需要自行维护版本冲突、依赖顺序等问题，开发和维护成本较高。

内容的提问来源于stack exchange，提问作者Sty