7

我们在实施 Team Foundation Build Server 时遇到了性能问题，我对如何加快速度没有任何想法。我们已经添加了一些 PropertyGroup 元素来提高几个步骤的性能（SkipClean、SkipLabel、SkipInitializeWorkspace），但我认为我们需要进行重大重组来解决问题。这是我们的设置：

  • 我们有大约 40 个 Web 应用程序，每个应用程序都非常不同，但运行的是一堆共享程序集
  • 这些 Web 应用程序中的每一个都有自己的解决方案；
  • 这些 Web 应用程序中的每一个都引用了大约 10 到 25 个共享程序集；
  • 存在一个构建定义，其中包含在每次签入主干时触发的所有解决方案；

这是我们遇到的基本问题

  • 在构建期间，它将构建每个共享程序集的引用次数，而不是构建一次并为每个应用程序使用
  • 放置目录的文件复制时间非常慢。它必须通过网络共享并且不会采用本地路径。
  • 每隔这么多构建，一个或多个输出文件就会“锁定”并导致构建中断，即使编译正常。
  • 还有一件事——我也尝试过单独的构建定义，但这样做也会强制在获取最新版本上获取另一个工作区。我更希望构建服务器包含一个版本的主干来构建。

在过去的几个月里，我们已经屈服于嗜睡并忽略了这个问题，但现在构建时间是一个多小时到一个半小时。

我正在玩弄学习和切换到巡航控制的想法，以获得更好的控制。有人不同意吗？

非常感谢任何帮助。谢谢！

4

4 回答 4

3

所以这就是我所做的，我已经把构建时间缩短到了 9 分钟。对于我正在编译的项目数量，我很好。

  • 创建了一个包含所有共享库和所有网站的解决方案。这一步有很多额外的工作，因为我必须修复一堆遗留代码或存储在多个地方的引用。
  • 最终节省最多时间的是执行文件系统移动，而不是所有输出文件的网络副本。由于我们的放置位置实际上位于构建服务器上，因此这是有道理的。

要执行移动，我只需覆盖 TFSBuild.proj 文件中的 CoreDropBuild 目标：

<Target Name="CoreDropBuild"
        Condition=" '$(SkipDropBuild)'!='true' and '$(IsDesktopBuild)'!='true' "
        DependsOnTargets="$(CoreDropBuildDependsOn)" >
             <Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>    
</Target>
于 2008-12-09T13:05:17.047 回答
2

首先，听起来好像您的所有 Web 应用程序都包含在同一个团队项目中。如果这是真的，请将它们分成逻辑分组。通常，单个团队项目应包含单个部署模型。

其次，将共享程序集拆分为他们自己的团队项目。移动后，您有几个选择，您可以将源或编译的 DLL 分支到需要它们的团队项目。他们可以有自己的单元测试，如果您愿意，您可以扩展团队构建以自动合并成功的测试。

总而言之，您需要简化构建策略。

于 2008-11-21T20:23:15.047 回答
1

您真的需要在每个 Web 应用程序中构建所有内容吗？如果共享程序集没有改变，为什么要一遍又一遍地构建它们？

这里有一个想法：

  1. 让每个 Web 应用程序都有自己的 \lib 文件夹。
  2. 将每个共享程序集放在 lib 文件夹中。
  3. 让 Web 应用仅引用其本地 lib 文件夹中的共享程序集。
  4. 检查一切。

现在，除非发生更改，否则不应开始构建，并且构建将不包括共享程序集。

  • 应该有一个包含所有共享程序集的中央文件夹。
  • 此处的任何更改都应传播到所有本地 \lib 文件夹。
  • 最后，任何共享程序集在发生更改时都应复制到中央文件夹。

这里的想法是让一个共享的程序集项目只知道中央文件夹。这将简化复制构建所需的任何构建后操作。

必须以这样一种方式管理中央文件夹，以便将任何更改复制到所有引用的 Web 应用程序。

于 2008-11-23T22:04:52.360 回答
0

Speaking from personal experience on the CruiseControl suggestion - remember it's a continuous integration "framework". It won't solve all your problems out of the box (componentized builds, firing on each component change, and serialized builds though will make things a lot better). It'll take quite some configuration (and maybe even customization) to get things how you want, so be prepared to invest some time. Of course, you'll reap a massive payoff in the long run if your build time gets right down - if you can't ignore the problem any more, it's worth investing some time on a better CI solution.

Be aware though that any CI effort is only as good as the policies you have in place. We had huge policy voids when it came to version labeling, releasing, dependencies, beta releases of binaries, archiving builds... and many other issues that we didn't even consider at the time.

Also, be prepared to dedicate at least some resources to maintaining the thing. It's not a full-time job (and I for one love doing it, since it produces continual process improvement). Our customizations have taken us from a 2 hour monolithic build of our first product to over 400 components in 20 products that build in parallel on multiple machines within about 20 minutes, so it's well worth it.

于 2008-11-21T22:23:02.030 回答