Процесс сборки - что использовать?

Question

Я подумываю о написании собственного кода доставки с использованием PowerShell и / или C #, возможно, прикрытия для NAnt или MSBuild.

1. Почему я должен не идти по этому пути? Это так сложно усилия по сравнению с использованием NAnt или MSBuild?
2. Какая-нибудь хорошая, современная книга, которая может помочь?
3. Есть идеи получше?

---

Справочная информация (П.С. Это религиозный вопрос для некоторых. Не должно быть никакого оскорбления):

Магазин для одного человека, несколько исследовательских проектов. Как и большинство из нас - сейчас windows и ASP.Net. Учитывая мобильность и облако.

Я начал вмешиваться в NAnt и пытался следовать Эксперт .Net Delivery Используя NAnt и CruiseControl.Net . Весь вопрос «доставки» был поставлен на лед, и теперь пришло время «разморозить» его. Тем не менее, я не уверен, куда идти. Из того, что я узнал:

NAnt показывает свой возраст. Это неуклюже: его гораздо сложнее понять и поддерживать, чем современный язык OO, такой как C #. Даже после того, как я последовал за книгой, кажется странным работать в непонятной среде, где нужно выполнить XML, а циклы и наследование (насколько я помню до «ледникового периода») трудно или невозможно.

MSBuid зависит от MS. Я даже не уверен, что он будет поддерживать не MS среду. Сервер Team Foundation стоит дорого.

Несмотря на это, они оба как-то дают ценность, потому что в моем поиске SO я не слышал, чтобы кто-то использовал их собственное программное обеспечение. Однако я не понимаю, почему бы не использовать C # и просто вызывать задачи NAnt и / или MSBuild по мере необходимости.

ТАК - НЕТ против MSBuild

Мой совет как раз наоборот - избегайте MSBuild, как чума. NANT намного проще настроить вашу сборку для автоматического тестирования, развертывания в нескольких производственных средах, интеграции с cruisecontrol для начальной среды, интеграции с контролем версий. Мы прошли через такую ​​большую боль с TFS / MSBuild (используя TFSDeployer, пользовательские сценарии PowerShell и т. Д.), Чтобы заставить его делать то, что мы могли делать с NANT из коробки. Не трать свое время.

SO - NAnt против скриптов :

Существует гораздо больше возможностей для создания продукта, чем просто его компиляция. Такие задачи, как создание установок, обновление номеров версий, создание условных выпусков, распространение окончательных пакетов и т. Д., Могут быть намного проще благодаря тому, что предоставляют эти инструменты (и их расширения). Хотя вы можете делать все это с помощью обычных скриптов, использование NAnt или MSBuild дает вам прочную основу для всего этого

Answer 1

NAnt как проект мертв или находится на жизнеобеспечении (последний выпуск был 0.86 beta 1, два года назад). Это было в основном прервано выпуском MSBuild. NAnt был хорош, MSBuild в порядке, я думаю, но я чувствую себя все более и более тяготеющим к написанию кода на языке, а не на процедурных вещах на основе XML. В основанных на XML фреймворках сборки процесс отладки ужасен, и вы в конечном итоге обманываете, встраивая «сценарии» в c #, что противоречит цели объявления по сравнению с программированием. Такая же печальная история, как и в XSLT.

Несколько хороших фреймворков без XML:

• Rake http://rake.rubyforge.org/ (на основе Ruby) довольно неплохо, и существуют некоторые специфичные для .NET задачи, и я думаю, что IronRuby выполняет его сейчас.
• PSake http://code.google.com/p/psake/ (на основе Powershell) - очень перспективный
• Подделка http://code.google.com/p/fake/ для искателей приключений, которые любят F #

Я все еще использую MSBuild, поскольку это формат файлов csproj, но для конкретных вещей я избегаю построения логики в XML (никаких пользовательских задач MSBuild).

Answer 2

В конце дня задачи MSBuild и NAnt могут передаваться в командную строку, поэтому в конечном итоге они могут поддерживать не-MS вещи.

Я бы лично предпочел MSBuild и позволил бы Build Server, например, TeamCity из CCNET, выполнять сборку и развертывание и т. Д. Это невероятно гибко.

Answer 3

Не используйте C # для построения скрипта, потому что вы не хотите компилировать его, когда вносите в него изменения.

Если вы планируете использовать PowerShell, посмотрите на PSake .

Если вы дружественны к XML, используйте MSBuild или NAnt. Возможно эти сценарии сборки полезны для вас. У MSBuild есть одно преимущество: Ctrl + F5 создает этот скрипт в Visual Studio.

Я медленно перешел на Rake, потому что он лучше, а Ruby - язык программирования (что означает, что вы можете делать все что угодно): Я писал в блоге о том, как это хорошо, но вы должны перевести его или посмотреть только код . Если вам это нравится, то вы можете увидеть полный сценарий и зависимости .

Хорошая книга о непрерывной интеграции принадлежит Полу Дювалю, Стиву Матиасу и Эндрю Гловеру (Непрерывная интеграция: повышение качества программного обеспечения и снижение рисков).

Answer 4

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

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

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

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

Answer 5

Я не вижу причин, почему бы не выполнить простой процесс сборки в Powershell.

Я использую следующее для своего проекта песочницы:

#Types
Add-Type -Path D:\Code\OSLib\SharpSvn-x64\SharpSvn.dll

#Tools
$svn = New-Object SharpSvn.SvnClient
$msbuild = 'D:\Windows\Microsoft.NET\Framework64\v4.0.21006\msbuild'
$mstest = 'D:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\mstest'

#Sandbox
$sandbox = New-Object SharpSvn.SvnUriTarget -argumentlist "http://dan:password@sevenmagoo:81/svn/sandbox/trunk/"
$workingdir = 'D:\Code\sandbox'
$builddir = 'D:\Build\sandbox'
$solution = $builddir + '\sandbox.sln'
$tests = '/testcontainer:D:\Build\sandbox\sandbox.Tests\bin\Debug\sandbox.Tests.dll'

function sandbox() { ii D:\Code\sandbox\sandbox.sln }
function build()
{   
     echo 'Empty build directory and recreate'
    rm -r -Force $builddir | out-null;
    md $builddir  | out-null; 

    echo 'Checkout successful? '
    $svn.Checkout($sandbox, $builddir);;


    echo 'Building'
    .$msbuild $solution /nologo;

    echo 'Testing'
    .$mstest $tests /nologo;;  
}

Айенде Рахин тоже сделала то же самое, здесь .

Надеюсь, это поможет,

Доброжелательность,

Dan

Answer 6

Одна вещь, о которой я до сих пор особо не упоминал: управление зависимостями / перестройкой. Хорошая система сборки (даже почтенная make) справится с этим для вас, и если вы создаете свою собственную систему сборки, вы делаете одну из двух вещей:

• Часто перестраивать все (или, по крайней мере, больше, чем нужно)
• Повторная реализация логики отслеживания зависимостей и обновления самостоятельно

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

Грустно слышать, что NAnt умирает, хотя; Ant имеет разумную и гибкую систему сборки.

Answer 7

Если вы намереваетесь оставаться «магазином для одного человека», и ваши проекты, как правило, небольшие, то вы, вероятно, можете обойтись без использования собственной системы сборки. Я бы по-прежнему рекомендовал этого не делать, поскольку иметь опыт работы с часто используемыми средами сборки - это хорошо иметь в своем резюме.

Я написал специальную систему сборки, которую мы использовали на работе около пяти лет назад для обработки некоторых довольно сложных многоцелевых сборок, которые у нас есть. Мы используем его с 2003 года и продолжаем его использовать. Тем не менее, я пытался переместить его в сторону Ant или даже Make по следующим причинам:

1. Система сборки, которую я написал, работает на Windows, и нам нужны другие платформы. Его можно было бы переписать так, чтобы он довольно легко выполнялся в другом месте, но код управления процессами трудно переносить легко.
2. Интеграция в среду CI является проблемой, если вы используете полностью настраиваемую среду.
3. Добавление поддержки для различных SCM технологий - несложная задача. До сих пор нам требовалась поддержка Visual SourceSafe, Subversion и Perforce.
4. Расширение и поддержание этого - большая работа, которую "не добавляет никакой ценности для клиента" .

Теперь наша среда немного сложнее, чем большинство, поскольку мы занимаемся разработкой встраиваемых систем, поэтому нередко бывает, что сборка одного продукта состоит из двух или трех различных цепочек инструментов в Windows, а оболочка для Linux-машины через ssh. для цели только для Linux и psexec на удаленной машине Windows для использования компилятора с блокировкой узла. Очень забавно оглянуться назад и подумать, что система сборки, которую мы начали с одного пакетного файла, была переписана с использованием Perl для размещения смеси декларативных операторов и операторов языка программирования, а затем снова написана в декларативном XML-подобном XML стиль, который обстреливает партию или раковину. Теперь я думаю о замене всего этого на Ant + Maven + Ivy или какую-то похожую цепочку.

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

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