使用版本控制(*.sqlproj)正确管理SSDT项目文件

Question

我们经常遇到项目XML文件(*.sqlproj)的问题。如果文件被添加/重命名/更改位置，那么它会自动添加/删除某些意外位置的记录。在此之后，我们有很大的麻烦，合并它时，有人也改变了该文件。

我们得出的结论是，我们可以在签入之前对其进行分类。我们将按字母顺序对其进行排序，在这种情况下，合并工具将更好地理解它。

所以，我的问题是：

1. 是否有可能在每次签入之前重新安排sqlproj文件？也许已经有某种选择或工具可以这样做了？
2. 还有其他方法让开发人员的生活更轻松吗？

更新：

我又一次遇到了同样的问题。sqlproj文件被修改了3次，我只想合并到生产上一次更改，其他2还没有测试。在合并工具中，我可以选择添加所有这3个新对象，或者不进行任何更改。我不能只选择最后一个改变..。

例子：

1. developerA创建tableA并签入；
2. developerB获得了开发分支的最新版本，创建了tableB并签入；
3. developerC获得了开发分支的最新版本，创建了tableC并签入。DeveloperC测试了代码并准备投入生产。他试图将他的代码合并到QA中，得到冲突，他只能选择所有的更改。

Answer 1

我很理解你遇到的情况。这种情况通常发生在单个存储库的上下文中有多个工作流，而且您没有一个共同的提升计划(因为在所有工作中，所有工作都将同时转到QA和PROD )。

我可以想出几种方法来解决这个问题，每个选项都有优缺点。

1. 锁定每一个环境，直到一切都能共同促进。在大多数情况下都不现实。
2. 当您准备好晋升时，从源环境中创建一个促销分支，并将未准备好升级到目的地环境的促销分支中的内容从推广分支中删除。这使得devs能够继续工作，并且能够在不冻结的情况下进行推广。
3. 混合方法..。在Dev中没有任何源代码控制，直到它准备好促进测试。然后从那里开始做第1或第2项选择。
4. 创建一个更灵活的生态系统，可以为每个特性分支创建一个环境，以便与其他功能分支进行演示/测试(或者至少在开发人员之间分配/轮换足够多的资源来实现相同的目标)。一旦被接受升职。这是我们目前正在努力实现的目标，但当你拥有大量共享数据库和应用程序的互联数据库和应用程序时，构建基础设施和流程至少是有点困难的(尤其是在微软世界)。

不管怎样希望这能帮上忙..。

Answer 2

1-你在使用什么源代码控制？据我所知，没有任何源代码管理能够理解sqlproj文件的上下文，但这通常不是一个问题。

2.a -这不应该是你经常遇到的问题，你定期报到吗？如果不同的开发人员对项目进行了大规模的更改，并且没有在项目前后签出/签入，我只希望看到问题。

2.b -这也可能是你没有正确合并，如果你采取这两套改变，那么它通常是好的。

边缘