build - 如何加速 Nant Builds？

Question

我们有许多编译 .NET 代码的 Nant 脚本。这些构建需要 5 到 10 分钟才能运行，我想找到一种方法来加速它们。

我们的 Nant 脚本看起来像

<target name="compile.XYZ" description="Compiles the source code">  
    <msbuild project="${src.dir}\XYZ.sln" verbosity="${build.verbosity}">
        <property name="Configuration" value="${build.config}" /> 
        <property name="OutputPath" value="${build.fullpath}/${prefix.xyz}" />
        <property name="ReferencePath" value="${assembly.dir}" />
    </msbuild>
</target>

它们都与此非常相似。我确实研究了 nant，但它看起来有点过时，所以我有点犹豫要不要使用它，尽管这可能非常方便，因为我们的构建中有多个目标。

您在提高这些构建的性能方面所能提供的任何帮助将不胜感激!

谢谢 :)

Answer 1

对于任何构建系统，需要注意的一件事是确保它了解所有依赖项。在您的情况下，您正在混合构建系统，这很好，但您必须确保 Nant 和 MSBuild 都知道您的依赖项。如果您有两个相互依赖的解决方案，将这些依赖项目移动到它们自己的解决方案中可能会有所帮助，以确保它们在构建周期内只构建一次。

确保您正在利用增量编译。如果您不信任发布候选的增量构建，请为发布与测试和开发构建使用单独的构建目标。还要确保您为正在运行的构建类型使用适当的编译器设置。

任何彼此之间没有编译时依赖性的解决方案都可以并行构建。而 MSBuild(3.5 及更高版本)natively支持在同一台机器上并行构建，而 Nant 不支持(它的 Java 兄弟，Ant 支持)。对此进行补偿的一种方法是创建一个仅供构建使用的主解决方案文件。这将允许 MSBuild 并行化独立项目。这个有点过时的 MSDN article列出不同解决方案/项目组织技术的优点和缺点。您可以通过设置构建场并在多台机器上构建独立的解决方案，将其提升到一个新的水平。大多数持续集成服务器都支持这一点。

另一件要考虑的事情是您的项目是否在多个开发项目中遵循 DRY 原则。如果两个不相关的项目具有类似目的的类，则可以将它们合并为一个类并移动到共享库中。通过消除代码重复，您不仅可以降低维护成本，还可以同时优化构建过程。如果您的开发人员专注于某些项目，那么在不相关的项目中查找重复是非常耗时的。