防止生产中不需要的液体变化集的最佳实践

Question

所以这是场景：

• 每2次冲刺就会推迟发布
• dev正在sprint中写入更改集，在表B中添加表A + 2列，提交它们，它被推送到QA，一切都很好。
• 在sprint演示期间，利益相关者确定他需要在表B中再增加2个字段，并且整个部分需要重新编写，导致删除表A，删除表B中的3列并在表B中添加2个新列< / LI>
• 下一个sprint，开发人员实现sprint演示中发现的更改（即将更改集添加到之前添加的drop table等）

=＆GT;所以现在我们有变更集，当它们部署到生产时基本上会创建一个表，然后立即删除它。对于上述最小的更改，这不是一个真正的问题，但对于更大的更改集，您最终可能会不必要地增加生产数据库事务日志。升级生产的时间也可能会有所增加，因为这些变更集可以恢复首先不需要完成的工作。

1. 是否建议重新设置变更集，以便在发布时只执行所需的变更集（基本上是重新设置2个冲刺的变更集）？
2. 或者你会有两组变更集（一组用于开发，用于累积冲刺期间所做的所有更改，一组用于生产，最大限度地减少更改量）。
3. 这是否违背了“错误是对的”原则（https://docs.google.com/presentation/d/1U8vESZVbj-zFE-K1Vh5dVfiH8xns9Gv9zDzg0DZBcKc/edit?pli=1#slide=id.g119ea23dc_00的第17页）

Answer 1

为生产排序创建单独的变更集会破坏跟踪迁移的全部目的。话虽这么说，如果你决定沿着这条道路前进，那就去看一下背景。您可以将某些更改集标记为已批准用于生产的更改集，并仅针对这些标记运行生产迁移。

Answer 2

我通常建议的是不要担心不必要的更改。他们可能会创建一个表然后再次删除它，但数据库真的很快就这样做了。

修改changeLog可以避免生产数据库制作和删除不必要的对象，但是在此过程中，由于在其上运行但不生产的changeSets，您的开发人员数据库很容易因生产而不同。此外，您已经进行的测试是针对原始命令流的，这可能适用于新功能，也可能不适用于新功能，您在部署到生产环境时不会感到意外。

我建议拔出changeSets的唯一时间是进行不必要的昂贵操作，例如createIndex后跟大表上的dropIndex。