我的团队正在评估用于管理数据库迁移的 dbdeploy。 据我了解，使用迁移需要一些流程规则，即为每个更改编写迁移，并且为了达到生产，必须将其从本地提升到开发、测试到生产。
有时，我们的生产 DBA 团队会直接对生产环境进行架构更改。 如果我们编写一个新的迁移来针对数据库的当前开发版本进行更改，则在将迁移部署到生产之前，该迁移将永远不会针对已包含更改的模式进行测试。 这让我很担心。
另一种选择是直接对基线模式进行更改，然后在所有环境（本地、开发、测试、阶段）中重建数据库。 我担心这种方法，因为新架构可能会导致一个或多个迁移中断。
人们目前如何处理这种情况？
My team is evaluating dbdeploy for managing database migrations. As I understand it, using migrations requires a bit of process discipline, namely that a migration is written for every change, and that to reach production, it would have to be promoted from local to development to test to production.
Occasionally our production DBA team makes schema changes directly to the production environment. If we write a new migration to make the change against our current development version of the database, that migration will never be tested against a schema that already contains the change until the migration is being deployed to production. This concerns me.
The other option is to make the change directly to the baseline schema, then rebuild the database in all environments (local, development, test, stage). This approach concerns me, because the new schema could cause one or more migrations to break.
How are people currently handling this scenario?
发布评论
评论（3）
我们连夜将生产数据库的副本恢复到测试服务器上。
然后，它可以：
我们不会重建开发/测试数据库等，但我们的一些其他项目会重建。 但是，我不确定这样做的好处，因为数据库不是模式和代码：它也是数据。 它与编译的 .net 应用程序不同。
在我的商店中，未经批准而对产品数据库进行更改（任何更改）的生产 DBA 将被解雇。 这已经发生了。
We restore a copy of our production DB onto a test server overnight.
This then serves:
We don't rebuild dev/test databases etc but some of our fellow projects do. However, I'm not sure of the benefit because a database is not schema and code: it's data too. It's different to a complied .net app.
In my shop, a production DBA making changes to a prod DB (any change at all) without approval would be fired. And it's happened.
生产模式上的数据库更改必须不时发生，这是可以理解的。 但非常重要的是，必须将这些记录下来并尽快传达给开发团队。 执行 SQL 的纯文本以及对受影响的用例/功能和可能的错误跟踪问题的注释可以
时不时地将实时数据库取回到开发中，并将其（它的模式）与开发人员所拥有的进行比较是一个好主意以及。
It is understandable that DB changes on the production schema have to happen from time to time. It is very important though that these have to be documented and communicated ASAP back to the development team. Plain text with the sql executed together with comments on affected use cases/functionalities and possible bug tracking issues would do
Fetching the live DB back to the development every now and then and comparing it (it's schema) with what the developers have is a good idea as well.
我认为 DBA 在生产数据库上唯一可以改变的就是到处添加索引并调整一些存储过程 - 所有这些都是为了性能。 一般来说，对数据库的所有其他更改都会导致数据库架构与应用程序不兼容。
考虑到这一点，唯一真正应该进行版本控制的是存储过程，DBA 有责任将它们签入源代码管理。 索引的波动性更大，实际上可能不包含在迁移脚本中。
I assume that the only thing DBA can change on production DB is to add an index here and there and tweak a few sprocs - all for the sake of performance. All other changes to the DB can, generally speaking, render DB schema to be incompatible with the application.
With this in mind, the only thing that actually should be versioned are sprocs, and it's the responsibility of a DBA to check them into source control. Indexes are much more volatile and may actually not be included in migration scripts.