Git TFS 2010多种解决方案&；使用门控签入构建

我在相应的文件夹中有两个解决方案，例如

SolutionA\SolutionsA.sln

SolutionB\SolutionB.sln

每个解决方案都配置了门控签入生成；i、 e.两个构建定义GatedSolutionA和GatedSolutionB

现在的情况是，如果我同时签入两个文件夹中的更改，TFS将显示一个对话框，选择build（使用GatedSolutionA、GatedSolutionB下拉菜单）以针对更改集运行。我的变更集在解决方案B中具有中断性变更，在解决方案A中具有非中断性变更。即，构建网关解决方案B将失败，但网关解决方案A将通过

当我选择GatedSolutionA根据我的变更集进行构建时，TFS会将其签入，从而使解决方案B处于中断状态，并且解决方案B的门控签入目的失败

如果我将生成定义的触发器更改为CI，TFS将对两个生成进行排队

我所寻找的是相同的行为，即所有封闭构建都排队，如果其中一个失败，则应拒绝变更集

注意：我不想为这两个解决方案创建单构建定义。另外，我知道我们可以通过创建两个单独的变更集来避免这个问题的发生，但通常情况下，当开发人员不知道他们正在签入一些文件以获取解决方案时，就会发生这种情况

2019年更新 由于TFS和Azure DevOps已经开始使用GIT和Pull请求-使用分支策略（在主分支上），因此可以添加多个构建检查，例如，对于路径

SolutionA\*

中的更改，可以将BuildA配置为排队和检查，对于路径

SolutionB\*

中的更改，也可以进行类似的配置，BuildB可以配置为排队和检查，因此对于两个路径都发生更改的提交，将对两个生成进行排队检查。等待使用GIT是值得的

分行政策：

---

注意：文档没有更新以显示路径过滤器，并且缺陷在github上提出。因此，该筛选器在Azure DevOps和服务器中可用。

在“进程”选项卡的“生成定义”中，您可以选择多个sln进行生成

这个问题的一个解决方案是让开发人员为单独的解决方案映射单独的工作空间。如果解决方案之间没有代码重叠，并且您试图阻止开发人员在构建另一个解决方案时签入一个解决方案，那么他们应该使用不同的工作空间

如果您有用于SolutionA的工作空间A和用于SolutionB的工作空间B，则“挂起的更改”对话框将仅显示对相应工作空间所做的更改

正如您所说，您知道可以通过使用单独的变更集来避免它。这就是您如何“强制”开发人员使用两个单独的变更集并避免“开发人员不知道…”的情况

---

为他们创建工作区并撤销他们的“创建工作区”权限，这样他们就不能创建一个同时包含这两个区域的工作区。

@gchave找到了解决该问题的方法，如果您将“源代码管理文件夹”配置到内部文件夹（其中有解决方案），您可以转到“编辑生成定义”和“工作区”选项卡

例如，如果您有此文件系统：

项目\SolutionA\SolutionA.sln

项目\SolutionB\SolutionB.sln

现在，如果您将“源代码管理文件夹”和“构建代理文件夹”配置为Projects\SolutionA，则只有在您尝试签入SolutionA时才会触发门控签入，并且它将只编译SolutionA.sln（要实现此功能，您必须只指向Process Tab->1.Required->ProjectsToBuild上的SolutionA.sln）

---

然后，您可以在同一个工作区下拥有多个解决方案，独立构建、签入和标记：）

我知道您说过“不想为两个解决方案创建单一构建定义”，但这确实是您唯一可行的选择。我建议有两个分支，一个用于功能开发，一个用于集成。让您的开发人员在功能分支中工作，并为这些解决方案使用门控签入（或CI）构建。定期将功能分支中的更改合并到一个集成分支中，该集成分支具有一个门控签入生成定义，用于生成所有解决方案。这将使集成分支的生成保持干净。

请问您为什么不想为两个解决方案创建一个生成定义？在我看来，这真的是这里唯一的解决方案。我们为每个解决方案都构建了CI。一个开发人员应该在一个时间点在一个解决方案中工作。当开发人员签入不打算签入的更改时，我遇到了此错误，因为您可能知道，从visual studio中，如果您从解决方案资源管理器签入更改，它将包含默认设置的所有文件对不起，但我仍然不确定您是否回答了我的问题。您可以有多个CI构建定义，但两种解决方案都可以有一个门控签入构建定义吗？在场景中，我们将以一小部分进行解释，在现实世界中，我有大约100个解决方案。事实上，我所解释的可以用来破解任何构建。这不是蝎子不想要的，一个构建所有解决方案的构建定义吗？