通过AWS Beanstalk部署Django至生产环境时的迁移问题

嘿，我之前在多环境部署Django的时候也踩过不少迁移的坑，结合你的场景给你梳理下具体的解决思路和操作规范：

首先得提一句：你当前Test环境直接连接生产RDS数据库的操作风险极高——测试过程中很容易误改生产数据，而且迁移执行的顺序也极易混乱。不过先针对你现有的工作流程，给出落地的解决方案：

1. 本地Dev环境的迁移规范 #

• 本地用sqlite3没问题，但每次模型变更后，生成的迁移文件必须保证向后兼容，这是核心前提：
  • 新增字段时，要么设置默认值（default=xxx），要么允许字段为空（null=True, blank=True），绝对不能直接添加非空且无默认值的字段，否则生产库执行迁移时会直接报错。
  • 如果要删除字段或修改字段类型，必须分两步走：第一步先把代码中对该字段的所有引用移除，部署到Test和Prod环境；第二步再生成删除/修改字段的迁移文件，执行迁移。
• 本地执行python manage.py makemigrations生成迁移文件后，一定要先在本地用python manage.py migrate测试一遍，确保迁移能在sqlite3上正常执行，不会出现数据损坏或逻辑错误。

2. Test环境的迁移执行要点 #

• 绝对不能在Test环境直接执行makemigrations——sqlite3和RDS常用的PostgreSQL生成的迁移文件可能存在差异，而且直接在生产库所在环境生成迁移很容易引发冲突。
• 正确流程：把本地生成并测试过的迁移文件提交到版本控制（比如Git），部署到Test环境后，先执行python manage.py migrate --dry-run做预检查，确认迁移逻辑没有问题，不会触发数据库错误。
• 如果dry run通过，再执行python manage.py migrate正式执行迁移，之后再跑测试用例。
• 重点注意：因为Test环境连的是生产库，测试时一定要用隔离的测试数据——比如用带test_前缀的表，或者在测试前开启事务，测试完成后立即回滚，绝对不能污染生产数据。

3. 从Test到Prod的迁移同步 #

• 因为Test环境已经在生产库执行过迁移了，Prod环境部署时，先拉取最新的迁移文件，然后执行python manage.py migrate --check检查当前数据库的迁移状态，确认哪些迁移还未执行。
• 正式执行迁移时，建议加上--no-input参数，避免部署过程中需要手动确认（Beanstalk是自动化部署，手动确认会导致部署失败）。
• 另外，Prod环境部署前一定要备份RDS数据库——哪怕迁移是向后兼容的，也能在出问题时快速回滚，降低损失。

4. 长期优化：隔离Test环境的数据库 #

其实你当前Test和Prod共用生产库的做法非常不推荐，强烈建议给Test环境单独创建一个RDS实例，和生产库结构保持一致：

• 可以定期从生产库创建快照，恢复到Test的RDS实例，这样Test环境的数据和生产环境接近，测试结果更准确，同时也完全避免了误操作生产数据的风险。
• 隔离后，Test环境可以自由执行迁移和测试，不用再小心翼翼地担心影响生产。

常见迁移问题排查 #

• 如果遇到迁移冲突（比如本地和环境的迁移文件编号不一致）：可以先在本地执行python manage.py migrate --fake把本地的迁移状态同步到数据库，然后重新生成正确的迁移文件。
• 如果迁移执行时报错（比如字段不存在、数据类型不兼容）：先检查迁移文件的执行顺序，确保向后兼容的步骤正确；必要时可以手动修改迁移文件，但修改后一定要在本地和Test环境都测试验证。

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