团队建设现在非常缓慢

Question

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

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

这是我们遇到的基本问题

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

在过去的几个月里，我们已经放弃了嗜睡并忽略了这个问题，但现在建造时间超过一小时到一个半小时。

我正在考虑学习和切换到Cruise Control以获得更好的控制权。有人不同意吗？

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

Answer 1

所以这就是我所做的，而且我的构建时间缩短为9分钟。对于我正在编译的项目数量，我很好。

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

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

<Target Name="CoreDropBuild"
        Condition=" '$(SkipDropBuild)'!='true' and '$(IsDesktopBuild)'!='true' "
        DependsOnTargets="$(CoreDropBuildDependsOn)" >
             <Exec Command="move $(BinariesRoot)\Release d:\BuildOutput\$(BuildNumber)\Release"/>    
</Target>

Answer 2

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

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

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

Answer 3

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

这是一个想法：

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

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

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

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

必须管理中央文件夹，以便将所有更改复制到所有引用的Web应用程序。

Answer 4

根据CruiseControl建议的个人经验 - 记住它是一个持续集成的“框架”。它不能解决您开箱即用的所有问题（组件化构建，触发每个组件更改，序列化构建虽然会使事情变得更好）。它需要一些配置（甚至可能是定制）来获得你想要的东西，所以要准备投入一些时间。当然，如果你的构建时间缩短，你将从长远来看获得巨大回报 - 如果你不能再忽视这个问题，那么值得投入一些时间来研究更好的CI解决方案。

请注意，任何CI工作都只能与您现有的政策一样好。在版本标记，发布，依赖关系，二进制文件的beta版本，归档版本以及当时我们甚至没有考虑过的许多其他问题上，我们有巨大的政策空白。

此外，准备至少投入一些资源来维护这件事。这不是一份全职工作（我喜欢这样做，因为它可以产生持续的流程改进）。我们的定制使我们从第一个产品的2小时单片构建到20多个产品中的400多个组件，在20分钟内在多台机器上并行构建，因此非常值得。