我的团队正在评估用于管理数据库迁移的 dbdeploy。据我了解，使用迁移需要一些流程规则，即为每个更改编写迁移，并且为了达到生产，必须将其从本地提升到开发、测试到生产。
有时，我们的生产 DBA 团队会直接对生产环境进行架构更改。如果我们编写一个新的迁移来针对数据库的当前开发版本进行更改，则在将迁移部署到生产之前，该迁移将永远不会针对已包含更改的模式进行测试。这让我很担心。
另一个选项是直接对基线架构进行更改，然后在所有环境(本地、开发、测试、阶段)中重建数据库。这种方法让我担心，因为新架构可能会导致一个或多个迁移中断。
人们目前如何处理这种情况？
最佳答案
我们连夜将生产数据库的副本恢复到测试服务器上。
这将提供:
- 作为引用副本(代码和数据)
- 我们可以重置所做的任何更改
- 我们可以根据真实数据进行测试
- 我们可以并排新旧代码的性能
- 我们可以生成 100% 安全的更改/回滚脚本(Red Gate)
我们不会重建开发/测试数据库等，但我们的一些其他项目会重建。但是，我不确定这样做的好处，因为数据库不是模式和代码:它也是数据。它与编译的 .net 应用程序不同。
在我的商店中，未经批准而对产品数据库进行更改(任何更改)的生产 DBA 将被解雇。它已经发生了。
关于sql-server - 如何将对生产数据库所做的架构更改合并到我的迁移管理流程中？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/765934/