如何维护具有大量分支的SQL Server DB

Question

我在git下有一个ASP.NET项目,我们遵循为一个功能使用分支的约定.我们刚刚开始使用SQL Server数据工具来管理架构更改(对它来说很新,所以我怀疑它可能有一些功能可以让我得到我需要的东西).

我正在寻找一些适用于其他团队的策略,这些团队管理具有不同数据库模式的分支之间的切换,然后成功地将分支合并在一起.理想情况下,在合并所有功能之后,我会隐式创建一个更新脚本,以便部署以便将版本发布到生产环境.

注意我正在使用SQL Server 2008 R2

Answer 1

该策略有多个部分。一方面是处理不同分支的存储，对我的团队来说效果很好的方法是为每个分支使用不同的 SQL Server 实例（而不是使用特定于分支的前缀或后缀来命名各个数据库，例如 MyDatabase_FeatureBranchX，这可能会失控）。这使得每个分支中的相应数据库具有相同的名称（为了清楚起见），但也允许给定分支的 SQL 资源（数据文件、访问权限等）进行物理和逻辑隔离。

至于第二个更有趣的方面（我认为这是您问题的主要意图），您可能会考虑利用基于代码的“迁移”方法 - 例如，使用FluentMigrator等。如果您拥有最初创建每个分支的标准基线架构，则可以在代码中创建适当的迁移，作为每个分支中功能开发的一部分（并将它们应用到该分支的 SQL 实例）。当需要将分支合并到主干时，您还需要合并然后应用该分支的迁移。

充其量，这意味着您可以在合并后简单地针对主干实例运行迁移工具，以便应用所有分支的迁移，因为这样的工具会自动跟踪已应用的迁移（通过自定义数据库表）并且不要重新应用它们。假设您还在整个开发过程中定期将主干代码（包括其迁移）合并到功能分支中，并且应用这些迁移，那么您还可以确保功能分支的架构保持最新，这可以最大限度地减少合并时令人讨厌的意外情况。

当将主干部署到生产环境时，将再次应用这些相同的迁移。FluentMigrator 提供各种运行程序：控制台应用程序、NAnt、MSBuild 和 Rake。

我强烈建议使用基于时间戳（例如 201210241033）的迁移 ID 策略，而不是简单的连续整数（1、2、...），以最大限度地减少冲突和不按预期顺序应用更改的可能性。