Redgate SQL源代码管理推荐的开发测试活动数据库工作流

Question

我们正在尝试开始使用SQL源代码管理，并有一些问题。

这就是我的目标。这个看起来有用吗？

1. 修改dev数据库表/proc
2. 在dev PC上提交到dev git分支
3. 将更改推送到中央回购
4. 对每个更改重复步骤1-3。
5. 将开发分支合并为测试分支
6. 在测试分支上使用Source“获取最新”
7. 将更改应用于测试DB
8. 重复步骤5-8，但从测试到活

注：-使用“共享数据库”开发模式。

问题：

• 这个看起来有用吗？
• Source能否将这些更改应用于测试和活动数据库
  • 或者，我是否需要购买SQL的副本，以便dev服务器执行此任务？

​

​

​

• 修正这里的图表：http://goo.gl/l2mJdt
• 在我的谷歌文件中有更多的笔记和经验

Answer 1

很好，您正在从存储库中部署数据库更改的版本副本，在我看来，这确实是很好的持续交付实践。

对你的问题有几点建议(我戴上了红门帽)

• 通常不建议将SQL源代码管理连接到活动环境。它投票寻找变化，这可能不是你想要的东西在你的生活系统。建议使用SQL，而不是对UAT/Production进行一次性部署。另外，您可能对红门部署管理器产品感兴趣。
• 您将在上面询问测试中的共享/专用模式。无论您是在开发分支中为开发人员使用共享数据库，还是在测试分支中使用专用模型，都无关紧要。如果对测试数据库的唯一更改来自一个地方(例如，您的git部署)，那么最好以专用模式运行该数据库。

我画了一个图解，对你的画做了一些调整。不确定您是否在使用CI服务器，但我已经添加了它也适用于流程中的位置。这个关系图假设了两个开发人员的专用模式，但这可能是一个共享数据库。

​

​

Answer 2

是的，我认为这应该可以。传统上，合并分支的问题会给迁移脚本带来麻烦，尽管Migrations V2的beta版正在处理这个问题以及其他问题。

如果您有某种类型的构建系统链接到您的存储库，您可能会自动完成后面的部分，其中部署它来使用SQL自动化包进行测试-例如，执行合并会触发类似于TeamCity的内容，然后自动更新测试以节省手动进行测试的时间。

Answer 3

是的，只要您使用正确的连接模型，这似乎是有效的。

红门(原因如下)并不认为这是最佳实践。他们更希望您也购买SQL比较。

您可以使用专用模型连接到所有数据库，但无法查看谁修改了特定对象，但可以从活动中合并修补程序。

我更喜欢这样：

• 开发人员使用共享模型进行连接
  • 然后，您可以看到谁修改了每个表/proc/etc。

​

• 我们还使用共享模型在dev服务器上保留一个工作文件夹。
  • 这使我们可以使用get-最新更新开发从现场补丁。

​

如果发布混合模型特征 (投票表决这里)，可能会更简单。

​

​