我在 git 下有一个 ASP.NET 项目，我们在其中遵循使用分支作为功能的约定。我们刚刚开始使用 SQL Server Data Tools 来管理架构更改（对它来说很新，所以我怀疑它可能具有让我满足我需要的功能）。
我正在寻找一些适用于其他团队的策略，这些团队管理具有不同数据库模式的分支之间的切换，然后成功地将分支合并在一起。理想情况下，在合并所有功能后，我会隐式创建一个更改脚本来部署以发布到生产环境。
注意我使用的是 SQL Server 2008 R2
问问题
1437 次
1 回答
0
这个策略有多个部分。一方面是处理不同分支的存储，而对我的团队来说效果很好的是为每个分支使用不同的 SQL Server 实例（而不是使用特定于分支的前缀或后缀命名单个数据库，例如 MyDatabase_FeatureBranchX，这可能会失控）。这使得每个分支中的相应数据库具有相同的名称（为了清楚起见），但也允许给定分支的 SQL 资源（数据文件、访问权限等）的物理和逻辑隔离。
至于第二个更有趣的方面（我认为这是您问题的主要意图），您可以考虑使用基于代码的“迁移”方法——例如，使用FluentMigrator等。假设您有一个标准基线模式，每个分支最初都是从中创建的，那么您可以在代码中创建适当的迁移，作为每个分支中功能开发的一部分（并将它们应用到该分支的 SQL 实例）。当需要将分支合并到主干时，您还将合并然后应用该分支的迁移。
充其量，这意味着您可以在合并后简单地对您的主干实例运行迁移工具，以便应用所有分支的迁移，因为这样的工具会自动跟踪已应用的迁移（通过自定义数据库表）并且不要重新应用它们。如果您还在整个开发过程中定期将主干代码（包括其迁移）合并到您的功能分支中，并且您正在应用这些迁移，您还将确保您的功能分支的架构保持最新，这最大限度地减少了合并时令人讨厌的意外。
当需要将主干部署到生产环境时，将再次应用这些相同的迁移。FluentMigrator 提供各种运行程序：控制台应用程序、 NAnt、MSBuild 和 Rake。
我强烈建议使用基于时间戳（例如 201210241033）的迁移 ID 策略，而不是简单的连续整数（1、2、...），以最大程度地减少冲突和更改应用超出预期顺序的可能性。
于 2012-10-24T14:33:14.803 回答