TFS 门控构建

Question

我们有很多解决方案，每个解决方案都有 Web 项目和解决方案中的 Web 项目引用的类库项目。最终，所有解决方案的程序集都进入一个网站

另请注意，同一个项目（Web 或类库）可能出现在多个解决方案中，并且所有解决方案还从 TFS 中的一个公共位置引用程序集

目前，我们为每个解决方案都有单独的构建，它们被设置为手动触发 因此，开发人员能够签入部分/不正确的签入，而没有意识到他们在一个或多个解决方案中注入了编译错误

所以我们最终决定对签入进行门控，以便阻止那些引入编译错误的更改签入

问题是我们如何进行？ 每个解决方案都很大，有 30 多个项目

如果我们为每个解决方案创建门控签入构建，构建将需要 20 多分钟才能完成，而对于开发人员来说，获得接受或拒绝其更改的反馈的时间太长了

一种解决方案可能是为单个 Web 项目创建门控签入构建，这将减少开发人员的反馈时间，但会导致创建和维护的构建过多 此外，当我们为每个项目构建并且开发人员跨项目（构建）更改公共文件时，一个构建可能会成功，而另一个可能会失败，因此允许开发人员签入仍然会破坏构建的更改

对于这样的场景是否有任何指导方针可以遵循？

Answer 1

我不知道这方面的任何指导，但是...

鉴于您进行封闭式构建的目标是验证您的团队代码没有破坏任何东西，那么我认为重点是检查项目构建和单元测试是否通过。其他的都可以跳过。

因此，虽然我无法直接回答您的问题（即 1 个与多个构建），但我想说您的问题是延迟等待一个封闭的构建提交。我可以从我尝试减少 TFS 构建时间的经验中提供一点智慧......

为了缩短构建时间，您可以禁用流程的其他可选部分，例如测试影响分析、源索引、工作区清理和标记。最后确保源映射尽可能小。

也就是说，您可能会发现最大的速度提升是确保源映射非常严格，以便它们只获取您绝对需要的源。

我会坚持使用较少的构建，每次构建的项目数量较多，但这只是个人喜好，并非基于任何科学！

最后，如果您在多个项目或解决方案之间共享文件，请认真努力将这些共享位重构到它们自己的程序集中。完成后，为它们制作 NuGet 包，并使用 NuGet 在您的其他项目中引用它们。这样，您不仅可以避免在共享代码更改时构建许多项目/解决方案，而且您可以明确选择应用程序使用哪些版本的通用代码，而不是基于构建时间的隐含意外。

将共享文件重构为共享 NuGet 包还可以提高构建速度。它还使共享依赖关系更加清晰。