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

Ответ 1

NAnt, поскольку проект мертв, или на жизнеобеспечении (последний выпуск был 0,86 бета 1, два года назад). Это было в основном прервано выпуском MSBuild. NAnt был хорош, MSBuild в порядке, я думаю, но я чувствую, что все больше и больше обращается к написанию кода, ну, вместо языка, основанного на XML-процедуре. С основами построения на основе XML опыт отладки ужасен, и вы в конечном итоге обманываете, встраивая "скрипты" в С#, который побеждает цель объявления над программированием. Та же печальная история, что и XSLT.

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

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

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

Ответ 2

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

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

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

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

Хорошая книга о непрерывной интеграции - от Paul Duvall, Steve Matyas и Andrew Glover (Непрерывная интеграция: повышение качества программного обеспечения и снижение риска).

Ответ 3

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

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

Ответ 4

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

Я использую следующее для проекта sandbox:

#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:[email protected]: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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

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

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

Печально слышать, что NAnt умирает; в то время как у него есть доля бородавок, Ant - разумная и гибкая система сборки.