我们有许多解决方案，每个解决方案都有解决方案中的Web项目所涉及的Web项目和类库项目。最终，所有解决方案的组件都会进入一个网站
另请注意，同一项目（Web或类库）可能出现在多个解决方案中，并且所有解决方案也引用来自TFS中公共位置的程序集
目前，我们为每个解决方案提供了单独的构建，并将它们设置为手动触发 因此，开发人员能够签入部分/不正确的签到，并且没有意识到他们在一个或多个解决方案中注入了编译错误
所以我们最终决定进行门控检查，以便在检入时停止引入编译错误的更改
问题是我们如何进行？ 每个解决方案都非常庞大，有超过30个项目
如果我们为每个解决方案创建门控签到版本，那么构建将需要20多分钟才能完成，这对于开发人员来说是太多时间来获得他们的更改被接受或拒绝的反馈
一个解决方案可能是为单个Web项目创建门控签入构建，这将减少开发人员的反馈时间，但这将导致创建和维护过多的构建 此外，当我们按项目构建并且开发人员跨项目（构建）更改公共文件时，一个构建可能会成功，而其他构建可能会失败，从而允许开发人员签入仍将破坏构建的更改
这样的场景是否有任何指导方针？
答案 0 :(得分：0)
我不知道这方面的任何指导，但......
鉴于您的门控构建的目标是验证您的团队代码没有破坏任何东西然后我认为重点是检查项目构建和单元测试通过。其他所有内容都可以跳过。
因此，虽然我无法直接回答您的问题（即1对多个版本），但我会说您的问题是等待门控构建提交的延迟。我可以从尝试减少TFS构建时间的经验中提供一些智慧......
为了缩短构建次数次，您可以禁用该过程的其他可选部分，例如测试影响分析，源索引，工作区清理和标签。最后确保源映射尽可能小。
那说你可能会发现最大的速度提升是确保源映射非常严格，这样它们才能获得你绝对需要的源代码。
我会坚持使用每个版本拥有大量项目的较少数量的版本，但这只是个人偏好，而不是基于任何科学！
最后，如果您在多个项目或解决方案之间共享文件，请认真努力将这些共享位重构为自己的程序集。完成后，然后为它们制作NuGet包，并使用NuGet在其他项目中引用它们。这样，您不仅可以避免在共享代码更改时构建许多项目/解决方案，还可以选择应用程序使用的公共代码版本，而不是基于构建时的隐式事故。
将共享文件重构为共享的NuGet包也可以提高构建速度。它还使共享依赖关系变得更加清晰。