我的团队正在评估 dbdeploy 以管理数据库迁移。据我了解，使用迁移需要一些流程纪律，即为每次更改编写迁移，并且要达到生产，必须将其从本地提升到开发，再从测试到生产。
有时，我们的生产 DBA 团队会直接对生产环境进行模式更改。如果我们编写一个新的迁移来针对我们当前的数据库开发版本进行更改，那么在将迁移部署到生产之前，将永远不会针对已经包含更改的模式测试该迁移。这让我很担心。
另一种选择是直接对基线模式进行更改，然后在所有环境（本地、开发、测试、阶段）中重建数据库。这种方法让我很担心，因为新模式可能会导致一个或多个迁移中断。
人们目前如何处理这种情况？
我们在一夜之间将生产数据库的副本恢复到测试服务器上。
然后服务：
我们不重建开发/测试数据库等，但我们的一些伙伴项目会这样做。但是，我不确定它的好处，因为数据库不是模式和代码：它也是数据。它与编译好的 .net 应用程序不同。
在我的商店中，未经批准对产品数据库进行更改（任何更改）的生产 DBA 将被解雇。它发生了。
生产模式上的数据库更改必须不时发生，这是可以理解的。尽管这些必须记录并尽快传达给开发团队，但这一点非常重要。带有执行 sql 的纯文本以及对受影响的用例/功能和可能的错误跟踪问题的评论就可以了
时不时地将实时数据库取回开发，并将其（它的模式）与开发人员所拥有的进行比较也是一个好主意。
我假设 DBA 可以在生产数据库上更改的唯一事情是在这里和那里添加一个索引并调整一些存储过程——所有这些都是为了性能。一般来说，对数据库的所有其他更改都会使数据库模式与应用程序不兼容。
考虑到这一点，唯一真正应该进行版本控制的是存储过程，DBA 有责任将它们检查到源代码控制中。索引更不稳定，实际上可能不包含在迁移脚本中。