Любые рекомендации по написанию скриптов сборки в Ant или MSBuild

Question

Я пытаюсь автоматизировать процесс сборки моих проектов (как java, так и .net) с помощью Ant и MSBuild.Я читал о них и знаю, как писать сценарии сборки в Ant и MSBuild.Но мне интересно, есть ли какие-либо рекомендации или лучшие практики для написания сценариев сборки в целом?Вот два, которые я нашел, но я хотел бы услышать больше от других разработчиков.

• При написании сценария сборки просто полагайтесь на элементы, которые находятся в элементе управления источником и доступны в рабочей папке при проверке источников.НЕ пишите сценарии сборки, которые зависят от элементов, которые не хранятся в системе контроля версий.
• Если проект содержит набор подсистем и каждая подсистема имеет собственные сценарии сборки, файл сборкиПроект должен просто вызывать сценарии сборки подсистем.Кроме того, эти файлы должны импортировать общий файл сборки, содержащий цели, такие как компиляция, тестирование, пакет и т. Д.

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

Вот рекомендации, которые я собрал из ответов:

1. Запускайте каждую сборку в чистой среде.Это означает, что для каждого сценария сборки требуется цель clean.
2. Сценарии сборки обычно должны включать цели compile, package и test.
3. Если продукт имеет разные линии разработки (например, dev, release), все они должны иметьтот же сценарий сборки.Но в эти сценарии должны передаваться различные параметры.
4. Сборки, выполняемые по линиям разработки, обычно содержат этапы компиляции, упаковки, развертывания и установки.Но сборки на линиях выпуска включают в себя дальнейшие шаги, такие как маркировка продукта и создание журналов изменений / заметок о выпуске.
5. Скрипты сборки также должны храниться в системе контроля версий.
6. стараться сохранить всеинформация о сборке в сценариях сборки, а не на сервере непрерывной интеграции (Bamboo, TeamCity и т. д.)
7. Если в вашей сборке используется параметр, который может измениться в будущем (например, сетевой адрес для копирования результатов сборки), не делайте этого.жестко запишите его в свой скрипт сборки.вместо этого используйте параметры сборки, чтобы упростить управление им.

Answer 1

Просто комментарий ко второму пункту, который вы упомянули выше:

Если проект содержит набор подсистем, и каждая подсистема имеет свои собственные сценарии сборки, файл сборкиПроект должен просто вызывать сценарии сборки подсистем.

Каждая подсистема должна иметь свой собственный файл сборки, но этот файл должен импортировать общий файл сборки.Общий файл сборки будет содержать такие цели, как компиляция, тестирование, пакет и т. Д.

http://ant.apache.org/manual/Tasks/import.html

Файлы сборки подсистемы очень просты, не содержат дублирования и содержат только информациюспецифичен для этой подсистемы (например, compile.classpath).

Answer 2

Если вы создаете приложения VisualStudio, вам лучше использовать msbuild вместо Ant.Команда msbuild выполнит сборку с использованием файла решения, созданного вашими разработчиками, и в основном будет эмулировать ту же сборку, что и они.

Если вы действительно хотите автоматизировать все, взгляните на Jenkins .Он имеет плагин, который может выполнять msbuild и будет автоматически запускать сборку каждый раз, когда кто-то вносит изменения.Я использую комбинацию fo msbuild и Ant с Jenkins.Я делаю сборку, используя msbuild, затем использую Ant, чтобы собрать и сжать все мои построенные артефакты.Затем люди могут загружать встроенные артефакты непосредственно из Jenkins.

Теперь, когда вы используете Java-приложения, вам придется использовать Ant.Я использую следующие рекомендации

• Для каждого сценария сборки требуется цель clean.Эта цель удаляет все файлы, которые были добавлены во время процесса сборки, возвращая рабочий каталог в состояние до того, как произошло clean.
• Я следую тому, что делает Maven при использовании имен целей, поэтому мои цели - это вещи с именамикак clean , compile и package .
• Также, следуя указаниям Maven, все мои встроенные файлы помещаются в каталог target,Таким образом, моя команда clean может просто выполнить <delete dir="${target.dir}/> и очистить все красиво и блестяще.
• Если у меня есть подпроект, каждый подпроект имеет свой собственный файл build.xml.Мой основной файл build.xml просто вызывает все файлы build.xml подпроектов.
• Использование Ivy .Это легко установить и легко использовать.У вас больше нет проблемы с хранением jar-файлов в вашем исходном хранилище или потерей тех версий файлов jar, от которых вы зависите.
• Черт, если вы можете, используйте Maven и покончите с этим.К сожалению, большинство старых проектов труднее mavenize , чем оно того стоит.
• Делайте ваши сборки, используя Jenkins в качестве сервера непрерывной сборки.И все сборки, которые покидают отдел (сборки UAT, QA и защиты), должны быть сборкой Jenkins.
• Поощряйте ваших разработчиков писать модульные тесты.Фактически, Jenkins может выполнять модульные тесты и отображать их результаты на своей странице сборки.
• Используйте другие вещи, такие как checkstyle, PMD, CPD, Findbugs и другие продукты для проверки кода.И, конечно же, Дженкинс может запустить каждый из них и отобразить симпатичные графики, которые можно использовать, чтобы показать вашему менеджеру, насколько усердно вы работаете.

Answer 3

В MSBuild цели должны указывать входы и выходы, где это возможно (для включения расчета зависимости). При необходимости используйте атрибут Returns, чтобы указать цель, которая возвращает элементы, отличные от тех, которые используются для расчета зависимости.

Входные и выходные элементы для данной цели должны быть сгенерированы с использованием либо преобразования элементов (для простых преобразований на основе пути), либо другой цели (для более сложных преобразований).

Для MSBuild pre-4.x, для целей, которые вы определяете в файле .targets, рассмотрите возможность использования следующего шаблона, чтобы потребители могли вводить свои собственные цели перед теми, которые вы определяете:

<PropertyGroup>
  <MyTargetDependsOn>
    Target1;
    Target2;
    SomeOtherTarget
  </MyTargetDependsOn>
</PropertyGroup>
<Target
  Name="MyTarget"
  DependsOnTargets="$(MyTargetDependsOn)">

</Target>

Это позволяет потребителям вводить свои собственные цели перед указанной целью, просто изменяя значение свойства MyTargetsDependsOn:

<PropertyGroup>
  <MyTargetDependsOn>
    $(MyTargetDependsOn);
    YetAnotherTarget
  </MyTargetDependsOn>
</PropertyGroup>
<Target
  Name="YetAnotherTarget">

</Target>

В MSBuild 4.x вы можете просто использовать атрибуты BeforeTargets и AfterTargets.