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

Question

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

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

---

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

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

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

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

MSBuid MS специфический. Я даже не уверен, поддержит ли он среду, отличную от MS. Командный фундаментный сервер дорог.

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

SO - NAnt Vs. MSBuild

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

SO - NAnt vs. scripts:

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

Answer 1

NAnt как проект мертв, или на жизнеобеспечении (последний выпуск был 0,86 бета 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

Я не вижу причины, почему бы не сделать простой процесс сборки в 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;; 
} 

Ayende Rahien сделал подобную вещь тоже here.

Надежда, что помогает,

Kindness,

Dan

Answer 3

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

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

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

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

Answer 4

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

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

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

Я медленно двигаюсь к Рейку, потому что это лучше, а Ruby - это язык программирования (что означает, что вы можете что-либо сделать): I blogged about how nice it could be, but you have to translate it or look at code only. Если вам это нравится, вы можете увидеть full script и dependencies.

Good book about continuous integration is from Paul Duvall, Steve Matyas and Andrew Glover (Continuous Integration: Improving Software Quality and Reducing Risk).

Answer 5

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

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

Answer 6

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

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

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

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

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

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

Answer 7

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

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

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

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