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

Question

我的团队正在评估dbdeploy以管理数据库迁移。据我了解，使用迁移需要一些流程规则，即为每次更改编写迁移，并且为了达到生产，必须从本地升级到开发，再到测试再生产。

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

另一种选择是直接对基线架构进行更改，然后在所有环境（本地，开发，测试，阶段）中重建数据库。这种方法让我感到担心，因为新模式可能会导致一个或多个迁移中断。

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

Answer 1

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

然后服务：

• 作为参考副本（代码和数据）
• 我们可以重置我们所做的任何更改
• 我们可以测试真实数据
• 我们可以并排新/旧代码表现
• 我们可以生成100％安全的更改/回滚脚本（Red Gate）

我们不会重建开发/测试数据库等，但我们的一些同事项目会这样做。但是，我不确定这个好处，因为数据库不是架构和代码：它也是数据。它与已编译的.net应用程序不同。

在我的商店中，生产DBA会在未经批准的情况下对prod DB（任何更改）进行更改。它发生了。

Answer 2

可以理解，生产模式上的数据库更改必须不时发生。尽管必须将这些文档记录下来并尽快通知开发团队，但这一点非常重要。执行sql的纯文本与受影响的用例/功能的注释以及可能的错误跟踪问题一起执行

不时地将实时数据库提取回开发并将它（它的模式）与开发人员的模式进行比较也是一个好主意。

Answer 3

我认为DBA在生产数据库上唯一可以改变的是在这里和那里添加一个索引并调整一些sprocs - 所有这些都是出于性能的考虑。一般而言，对DB的所有其他更改都可能导致DB模式与应用程序不兼容。

考虑到这一点，实际应该版本化的唯一事情是sprocs，并且DBA有责任将它们检查到源代码控制中。索引更易变，实际上可能不包含在迁移脚本中。