Django数据库迁移测试：选已有数据库还是全新库？

核心疑问解答 #

两种迁移测试方式各有侧重，都有存在的价值：

• 全新数据库测试：能快速验证迁移文件的语法正确性、顺序合理性，确保迁移流程能正常执行。适合开发阶段快速验证模型变更后的迁移能否跑通，以及CI中自动化验证迁移的基础正确性。
• 生产备份/已有数据测试：用于验证迁移对现有数据的兼容性，比如字段重命名、数据转换、字段类型变更等场景下，数据是否能正确迁移、不会丢失或损坏。这是上线前必须做的验证，避免生产环境出问题。

开发者本地测试时：

• 全新数据库的流程（先apply旧迁移→makemigrations→apply新迁移）完全可行，适合快速排查迁移的语法或顺序问题；
• 但如果迁移涉及数据逻辑（比如自定义RunPython操作、字段类型变更），必须用带真实数据的库（生产备份脱敏后）测试，才能发现数据层面的问题。

全新数据库测试的注意事项 #

• 严格遵循迁移执行顺序：必须先应用所有历史迁移文件，再生成并应用新迁移，确保迁移的依赖链和执行顺序符合Django的预期，避免出现迁移冲突或顺序错误。
• 验证反向迁移：执行python manage.py migrate <app_name> zero回滚所有迁移，再重新apply全部迁移，确认反向迁移能正常工作——这是生产环境出问题时回滚的保障，尤其重要。
• 注意SQLite的特性限制：SQLite不支持部分ALTER TABLE操作（如修改字段类型、删除字段），Django会用「新建表→迁移数据→删除旧表」的模拟方式处理。这种操作在全新库可能没问题，但在有大量数据的生产库会有性能风险，因此即使全新库测过，也要用带数据的库验证这类迁移的可行性。
• 确保迁移幂等性：自定义迁移（如RunPython）要保证多次执行不会导致数据重复或错误，Django自动生成的迁移默认是幂等的，但自定义逻辑需要额外注意。

Gitlab CI中验证迁移正确性的流程 #

在CI流水线中加入专门的test-migrations阶段，确保每次代码推送都自动验证迁移：

1. 初始化环境：使用Docker镜像搭建包含Python、Django依赖的环境，直接使用SQLite（无需额外数据库服务，只需指定数据库文件路径）。
2. 基础迁移验证：

   # 初始化全新数据库并应用所有迁移
   python manage.py migrate --no-input
   

   验证迁移能无报错执行完成，说明迁移文件语法和顺序没问题。
3. 反向迁移测试：

   # 回滚到某个历史迁移版本，再重新应用
   python manage.py migrate <app_name> <previous_migration_hash>
   python manage.py migrate --no-input
   

   确认回滚和重应用过程无报错，保证迁移的可回滚性。
4. 数据兼容性测试（可选但推荐）：
   如果迁移涉及数据转换，提前在CI中导入脱敏后的生产备份数据，再执行迁移，验证数据转换逻辑是否正确。比如：

   # 导入脱敏数据
   sqlite3 db.sqlite3 < test_data.sql
   # 执行迁移
   python manage.py migrate --no-input
   # 验证数据状态（比如用自定义脚本检查字段值是否符合预期）
   python manage.py check_data_migration
   

5. 结合单元测试：迁移完成后运行项目单元测试，确保模型与数据库的交互正常，新字段、关联关系能正确读写。

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