Любая лучшая практика для написания сценариев сборки в муравьеде или MSBuild

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

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

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

Вот руководящие принципы, которые я собирал от ответов:

1. запускают каждую сборку в чистой среде. Это означает, что каждый скрипт сборки нуждается в Clean цели.
2. Сценарии сборки обычно должны включать компилирование , пакет , тест и Targets .
3. Если продукт имеют разные линии развития (например, Dev, выпуск), Все они должны иметь тот же сценарий сборки. Но, разные Параметры должны быть переданы этим скриптам.
4. сборки, выполняемые на линиях развития, обычно содержат компиляцию, Упаковка, развертывание и установка шагов. Но строит релиз Линии включают в себя дополнительные шаги, такие как пометка продукта и Создание заметок изменений-журналов / выпуска.
5. Сценарии по сборке также должны храниться на контроле источника.
6. Постарайтесь сохранить всю информацию об сборке в сценариях сборки, а не на Сервер непрерывной интеграции (Bamboo, TeamCity и т. Д.)
7. Если ваша сборка использует параметр, который может измениться в будущем (например, Сетевой адрес, чтобы скопировать результаты сборки), не заставляйте его в ваш сценарий сборки. Вместо этого используйте параметры сборки для его контроля с легкостью.