asp.net – 如何维护具有大量分支的SQL Server DB

发布时间：2020-12-16 07:40:05 所属栏目：asp.Net 来源：网络整理

导读：我在git下有一个ASP.NET项目,我们遵循为一个功能使用分支的约定.我们刚刚开始使用SQL Server数据工具来管理架构更改(对它来说很新,所以我怀疑它可能有一些功能可以让我得到我需要的东西). 我正在寻找一些适用于其他团队的策略,这些团队管理具有不同数据库模

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

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

注意我正在使用SQL Server 2008 R2

解决方法

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

至于第二个更有趣的方面(我认为是你问题的主要意图),你可以考虑使用基于代码的“迁移”方法 – 例如,使用FluentMigrator等.如果您有一个标准的基线模式,最初创建每个分支,您可以在代码中创建适当的迁移,作为每个分支中功能开发的一部分(并将它们应用于该分支的SQL实例).当将分支合并到主干时,您还要合并然后应用该分支的迁移.

充其量,这意味着您可以在合并后简单地针对您的主干实例运行迁移工具,以便应用所有分支的迁移,因为这样的工具会自动跟踪已应用的迁移(通过自定义数据库表)并且不要重新申请他们.如果您在整个开发过程中定期将主干代码(包括其迁移)合并到功能分支中,并且您正在应用这些迁移,那么您还需要确保功能分支的模式保持最新,它最大限度地减少了合并时令人讨厌的惊喜.

在将主干部署到生产环境时,将再次应用这些相同的迁移. FluentMigrator提供各种runners：控制台应用程序,NAnt,MSBuild和Rake.

我强烈建议使用基于时间戳(例如,201210241033)的迁移ID策略,而不是简单的顺序整数(1,2,…),以最小化从预期序列中应用冲突和更改的可能性.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!