Как ускорить сборку Nant? - PullRequest
Новая
       7

Как ускорить сборку Nant?

4 голосов
/ 10 февраля 2010

У нас есть несколько скриптов Nant, которые компилируют код .NET. Эти сборки занимают 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, но это выглядело немного устаревшим, поэтому я немного не решаюсь его использовать, хотя это может быть очень удобно, так как в нашей сборке есть несколько целей.

Буду очень признателен за любую помощь в улучшении производительности этих сборок!

Спасибо:)

Ответы [ 4 ]

4 голосов
/ 11 февраля 2010

Одна из вещей, на которые следует обращать внимание в любой системе сборки, - это убедиться, что она знает обо всех зависимостях. В вашем случае вы смешиваете системы сборки, и это нормально, но вы должны убедиться, что и Nant, и MSBuild знают ваши зависимости. Если у вас есть два взаимозависимых решения, может быть полезно переместить эти зависимые проекты в собственное решение, чтобы гарантировать, что они собираются только один раз в течение цикла сборки.

Убедитесь, что вы используете инкрементную компиляцию. Если вы не доверяете инкрементным сборкам для кандидатов на выпуск, используйте отдельные цели сборки для выпусков и тестов и сборок разработки. Также убедитесь, что вы используете соответствующие настройки компилятора для типа выполняемой сборки.

Любые решения, которые не имеют зависимостей времени компиляции друг от друга, могут быть построены параллельно. В то время как MSBuild (3.5 и более поздние версии) изначально поддерживает параллельные сборки на одной и той же машине, Nant не поддерживает (однако его аналог Java, Ant делает). Один из способов компенсировать это - создать основной файл решения, который используется только при сборке. Это позволило бы MSBuild распараллеливать независимые проекты. В этой слегка устаревшей статье MSDN перечислены преимущества и недостатки различных методов организации решений / проектов. Вы можете перейти на следующий уровень, настроив сборочную ферму и создав независимые решения на нескольких компьютерах. Большинство серверов непрерывной интеграции поддерживают это.

Еще одна вещь, которую стоит рассмотреть, - следуют ли ваши проекты принципу СУХО в нескольких проектах разработки. Если два несвязанных проекта имеют классы с похожими целями, их можно объединить в один класс и перенести в общую библиотеку. Удаляя дублирование кода, вы не только снижаете затраты на обслуживание, но и оптимизируете процесс сборки. Поиск дубликатов в несвязанных проектах занимает много времени, если ваши разработчики специализируются на определенных проектах.

3 голосов
/ 10 февраля 2010

Чем больше проектов в вашем решении, тем больше времени займет сборка. То же самое с количеством решений.

Ничего особо не поделаешь. Кстати, это не Нант, который здесь медлителен, это msbuild.

Вы могли бы попробовать некоторые предложения Скотта Хансельсмана:

http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx

В сущности, для этого требуется, чтобы вы передали «BuildInParallel =« true »» задаче, хотя есть определенные предостережения.

Это позволит параллельно создавать проекты в рамках одного решения, но я не вижу способа построить несколько решений параллельно.

Для этого вы могли бы создать мета-решение (поддерживается только вручную или автоматически генерироваться в nant до завершения сборки), в котором вы добавляете в него все различные проекты.

1 голос
/ 10 февраля 2010

Другой способ - разделить задачи MSBuild, основываясь на понимании вашего кода. Вы можете использовать параметр / m: x, чтобы указать, сколько процессоров можно использовать. Или просто / м, чтобы использовать все.

Некоторые ссылки для просмотра:

1 голос
/ 10 февраля 2010

Если у вас достаточно оперативной памяти, я бы купил приложение RAM Disk (я использую one с хорошими результатами).

Установите свой источник на этот диск, установите Nant. Установите там сторонние библиотеки и другую вспомогательную инфраструктуру. Это должно дать по крайней мере 33% до 50% скачка перфорации.

Кроме того, получите SSD и установите на него ОС и .NET Framework. Вместе вы сможете урезать его дальше.

...