TFS 2010 多种解决方案&构建门控签入
我在相应的文件夹中有两个解决方案，例如
SolutionA\SolutionsA.slnSolutionB\SolutionB.sln
每个解决方案都配置了门控签入构建；即两个构建定义 GatedSolutionA 和 GatedSolutionB。
现在的情况是，如果我同时签入两个文件夹中的更改，TFS 将显示一个对话框，用于选择构建（下拉菜单中包含 GatedSolutionA、GatedSolutionB）以针对更改集运行。我的变更集在解决方案 B 中具有重大更改，在解决方案 A 中具有非重大更改。即，构建 GatedSolutionB 会失败，但 GatedSolutionA 会通过。
当我选择 GatedSolutionA 来针对我的变更集进行构建时，TFS 会将其签入，这反过来又会使解决方案 B 处于损坏状态，并且解决方案 B 的门控签入目的将被破坏。
如果我将触发器更改为 CI 以进行构建定义，TFS对两个构建进行排队。
我正在寻找的是相同的行为，即所有门控构建都排队，如果其中之一失败，则应拒绝变更集。
注意：我不想为这两个解决方案创建单个构建定义。另外，我知道我们可以通过创建两个单独的变更集来避免此问题的发生，但是当开发人员不知道他们正在签入一些文件以获取除他们正在处理的解决方案之外的解决方案时，通常会发生这种情况。
更新 2019
由于 TFS 和 Azure DevOps 已开始使用 GIT 和 Pull 请求 - 使用分支策略（在主分支上），可以添加多个构建检查，例如路径更改 SolutionA\*< /code>，BuildA 可以配置为排队和检查，同样，对于路径 SolutionB\* 中的更改，BuildB 可以配置为排队和检查，因此对于在两个方面都有更改的提交路径将对两者进行排队用于检查的构建。使用 GIT 的等待是值得的。
注意：文档未更新以显示路径过滤器，并且在 github 上提出了缺陷 https://github.com/MicrosoftDocs/vsts-docs/issues/3235。因此，该过滤器可在 Azure DevOps 和服务器中使用。
I have two solutions in their corresponding folder e.g.
SolutionA\SolutionsA.slnSolutionB\SolutionB.sln
Each solution has Gated Check-in build configured; i.e. two build definitions GatedSolutionA and GatedSolutionB.
Now the situation is, if I check in changes in both folders together TFS shows a dialog box to select build (drop down with GatedSolutionA, GatedSolutionB) to run against the changeset. My changeset has breaking changes in solution B and non-breaking changes in Solution A. i.e. Build GatedSolutionB would fail but GatedSolutionA would pass.
When I select GatedSolutionA to build against my changeset, TFS checks it in, which in turn leaves the solution B in broken state and purpose of Gated check-in is defeated for Solution B.
If I change the trigger to CI for build definitions, TFS queues both builds.
What I am looking for is same behaviour i.e. All the Gated builds are queued and if one of them fails, changeset should be rejected.
Note: I don’t want to create single build definition for both the solutions. Also, I know we can avoid this problem to happen by creating two separate changesets, but this is generally happening when developers are not aware that they have some files being checked in for solution other than they are working on .
Update 2019
Since TFS and Azure DevOps have started using GIT and Pull request - using branch policies (on master branch) one can add more than one build checks e.g. for changes in path SolutionA\*, BuildA can be configured to be queued and checked, and similarly for changes in path SolutionB\*, BuildB can be configured to be queued and checked, and consequently for a commit having changes in both paths will queue both the builds for checking. Wait for using GIT was worth it.
Branch Policies: https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#build-validation
Note: documentation is not updated to show the path filter, and defect is raised on github here https://github.com/MicrosoftDocs/vsts-docs/issues/3235. As such the filter is available in Azure DevOps and Server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
@Gchaves 找到了该问题的解决方案，如果您将“源代码管理文件夹”配置为包含 SolutionA 的内部文件夹，则可以转到“编辑构建定义”和“工作空间”选项卡。
例如，如果您有以下文件系统：
现在，如果您将“源代码控制文件夹”和“构建代理文件夹”配置到 Projects\SolutionA，门控签入将仅当您尝试签入 SolutionA 时才会触发，并且它只会编译 SolutionA.sln（为此，您必须仅指向“进程”选项卡上的 SolutionA.sln ->1.Required->ProjectsToBuild)
然后您可以在同一工作空间下拥有多个解决方案，独立构建、签入和标记:)
@Gchaves found a solution for that problem, you can go to "Edit Build Definitions" and on "Workspace" tab if you configure your "Source Control Folder" to the inner folder, where you have SolutionA.
For instance, if you have this file system:
Now if you configure "Source Control Folder" and "Build Agent Folder" to Projects\SolutionA, the Gated check-in will only be triggered when you try to checkIn SolutionA, and it will only compile SolutionA.sln (for this to be true you must have to point just to SolutionA.sln on Process Tab ->1.Required->ProjectsToBuild)
And then you can have multiple solutions under same workspace, building, checking in and labeling independently:)
在“进程”选项卡的构建定义中，您可以选择多个 sln 进行构建。
In build definition at Process tab you can choose more then one sln to build.
我知道您说过“不想为这两个解决方案创建单个构建定义”，但这实际上是您唯一可行的选择。我建议有两个分支，一个用于功能开发，一个用于集成。让您的开发人员在功能分支中工作，并为这些解决方案使用门控签入（或 CI）构建。定期将功能分支中的更改合并到集成分支中，该集成分支具有可构建所有解决方案的单一门控签入构建定义。这将使集成分支的构建保持干净。
I know that you said that you "don’t want to create single build definition for both the solutions," but that's really you're only viable option here. What I'd suggest is having two branches, one for feature development and one for integration. Have your developers work in the feature branch(es) and use gated check-in (or CI) builds for those solutions. Periodically merge the changes in the feature branch(es) into an integration branch that has a single gated check-in build definition that builds all of your solutions. That will keep the builds from your integration branch clean.
此问题的一种解决方案是开发人员为单独的解决方案映射单独的工作区。如果解决方案之间没有代码重叠，并且您试图阻止开发人员在构建另一个解决方案时检查一个解决方案，那么他们应该使用不同的工作区。
如果解决方案 A 具有工作空间 A，解决方案 B 具有工作空间 B，则挂起的更改对话框将仅显示对相应工作空间所做的更改。
正如您所说，您知道可以通过使用单独的变更集来避免这种情况。这就是您如何“强制”开发人员使用两个单独的变更集并避免“开发人员不知道......”情况的方法。
为他们创建工作区并撤销他们的“创建工作区”权限，以便他们无法创建包含这两个区域的工作区。
One solution to this problem is for the developers to have separate workspaces mapped for the separate solutions. If there is no code overlapping between the solutions and you are trying to prevent a developer from checking into one solution when they are gated building another solution, then they should be using different workspaces.
If you have WorkspaceA for SolutionA and WorkspaceB for SolutionB, then the pending changes dialog will only show changes made to the appropriate workspace.
As you say, you know you can avoid it by using separate changesets. This is how you might "force" a developer to use two separate changesets and avoid the "developers are not aware..." situation.
Create the workspaces for them and revoke their "Create a workspace" permission so that they can't make one that includes both areas.