如何将对生产数据库所做的架构更改合并到我的迁移管理流程中？

Question

我的团队正在评估用于管理数据库迁移的dbdeploy。据我所知，使用迁移需要一些流程纪律，即为每个更改编写迁移，并且为了达到生产，它必须从本地到开发再到测试再到生产。

有时，我们的生产DBA团队会直接对生产环境进行模式更改。如果我们编写一个新的迁移来对数据库的当前开发版本进行更改，则在将迁移部署到生产环境之前，永远不会针对已包含更改的架构测试该迁移。这让我很担心。

另一种选择是直接对基线模式进行更改，然后在所有环境(本地、开发、测试、阶段)中重建数据库。这种方法与我有关，因为新的模式可能会导致一个或多个迁移中断。

人们目前是如何处理这种情况的？

Answer 1

我们连夜将生产数据库的副本恢复到测试服务器上。

这将提供以下服务：

• 作为参考拷贝(代码和数据)
• 我们可以重置我们所做的任何更改
• 我们可以针对真实数据进行测试
• 我们可以并排测试新旧代码性能

< code >H19我们可以生成100%安全的更改/回滚脚本(红门)

我们不会重建dev/test数据库等，但我们的一些伙伴项目会这样做。然而，我不确定它的好处，因为数据库不是模式和代码:它也是数据。这与一个复杂的.net应用程序不同。

在我的商店里，生产DBA在未经批准的情况下对prod DB进行更改(任何更改)都会被解雇。它已经发生了。

Answer 2

可以理解的是，生产模式上的数据库更改必须时不时地发生。但是非常重要的是，这些都必须被记录下来，并尽快传达给开发团队。执行sql的纯文本以及有关受影响的用例/功能和可能的错误跟踪问题的注释就可以了

每隔一段时间将实时数据库返回到开发中，并将其(它的模式)与开发人员所拥有的进行比较也是一个好主意。

Answer 3

我假设DBA在production DB上唯一可以更改的就是在这里和那里添加一个索引，并调整一些sprocs --所有这些都是为了提高性能。一般而言，对DB的所有其他更改都会使DB模式与应用程序不兼容。

考虑到这一点，实际上唯一需要版本化的是sprocs，DBA有责任将它们签入到源代码控制中。索引的易失性要高得多，实际上可能不会包含在迁移脚本中。