使用数据库部署工具进行并发功能开发

Question

我正在寻找一种特定的策略/约定，适用于使用功能分支和数据库部署工具（如DbUp，DbDeploy，ReadyRoll等）进行并发开发。

我们为并发项目开发运行多个功能分支。

每个分支都有专门的开发，QA和UAT环境，通过Octopus部署进行部署。

我正在尝试使用Octopus处理自动数据库部署，该工具将处理每个分支中应用的更改。

数据库更改将在所有分支（包括发布分支）中发生。

到目前为止，我所看到的大多数工具都使用了基于序列的脚本方法，这些方法被检入VCS并由工具部署。大多数情况下，该工具以升序的文件名顺序应用脚本，而我所看到的大部分都指定遵循1,2,3等的方法。

这适用于一个分支。

我的问题是当功能A有1而功能B有1时 - 两者都合并到主分支。我现在有两个＃1脚本。让它更有趣 - 我们的生产之路是再合并一次，也可能有1.所以现在我们有3＃1脚本。

还存在向后合并的问题。项目完成后 - 将发布分支合并回main，然后再次合并到功能分支，以便为下一个项目重置它。在这种情况下 - 我还有两个尚未应用于目标功能分支数据库的＃1脚本。

我对此的初步解决方案是使用julian日期作为检入源的sql文件名的前导前缀。我还在考虑将分支名称与工作项一起应用于文件。所以sql文件遵循{XXXXX_Y_ZZZZZZ.sql}约定，其中xxxxx是julian日期，y是分支，zzzzzz是TFS的工作项。

我正在寻找这个问题的具体解决方案。有没有人解决过这个问题？你做了什么？有什么缺点？你用了什么工具？

Answer 1

你有没有看过Readyroll的semantic versioning？

我们现在正在实施Readyroll，我们是一个小团队，在这个团队中，它很容易沟通并限制功能分支之间的变化。

我们在早期集成到开发分支并检测冲突的更改，并在必要时基本上重写早期的迁移脚本（这需要具有您可以恢复的数据库项目的基线）

在Redgate网站上，有一些关于与分支机构合作的信息，但并不完全涵盖您的情景，switch branches with readyroll。

在查看工具时，我基本上得出结论，它是基于状态的方法或基于迁移的方法之间的选择。我喜欢readyroll对它的看法，它提供了混合。

我很好奇你最终得到了什么！