部署流水线中如何处理第三方Django应用的数据库迁移？

核心需求 #

把第三方依赖modeltranslation-lokalise生成的迁移文件纳入版本控制，保证各环境数据库变更可追踪、可复制，避免同一迁移被重复执行。

可行方案及分析 #

方案1：提取迁移到项目目录并纳入版本控制（推荐） #

这是最可靠的方式，具体操作步骤：

• 先在本地执行python manage.py makemigrations，触发第三方包生成迁移文件
• 找到该包的迁移目录（通常在虚拟环境的site-packages/modeltranslation_lokalise/migrations/路径下）
• 将所有迁移文件复制到项目内的自定义目录，比如third_party_migrations/modeltranslation_lokalise/
• 在Django的settings.py中配置MIGRATION_MODULES，指定该应用的迁移路径：

  MIGRATION_MODULES = {
      'modeltranslation_lokalise': 'third_party_migrations.modeltranslation_lokalise',
  }
  

• 删除原第三方包目录下的迁移文件，防止Django读取到重复的迁移
• 将项目内的third_party_migrations目录添加到版本控制

优点：完全掌控迁移文件，名称固定，不会出现重复执行问题，各环境的迁移逻辑完全一致；后续可以直接追踪迁移文件的变更历史。
注意：每次更新modeltranslation-lokalise依赖后，要检查是否有新的迁移需要提取，避免遗漏依赖版本升级带来的数据库变更。

方案2：构建阶段生成迁移（不推荐） #

如果在Dockerfile中执行python manage.py makemigrations，会遇到致命问题：迁移文件名包含时间戳，每次构建生成的文件名不同，Django会判定为新的迁移，导致同一数据库变更被重复执行，破坏数据一致性。即便依赖版本不变，构建环境的细微差异也可能导致迁移生成结果不一致，所以这种方式风险极高，不建议采用。

生产部署流程（基于方案1） #

1. 拉取包含自定义迁移目录的项目代码
2. 安装所有依赖（包括modeltranslation-lokalise）
3. 执行python manage.py migrate，Django会自动读取项目内的迁移文件，执行未应用的数据库变更
4. 无需在构建或部署阶段额外执行makemigrations

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