Платформа автоматической сборки для портфолио .NET - лучший выбор? [закрыто]

Я занимаюсь поддержкой довольно большого портфеля приложений .NET. Также в портфолио представлены устаревшие приложения, созданные на основе других платформ - нативных C ++, ECLIPS Forms и т. Д.

У меня есть сложная инфраструктура сборки поверх NAnt, которая управляет сборками для всех этих приложений. Фреймворк сборки использует NAnt для выполнения различных задач:

• Извлекать код из Subversion, а также создавать теги в Subversion
• Соберите код, используя MSBuild для .NET или другие компиляторы для других платформ.
• Заглянуть в файлы AssemblyInfo для увеличения номеров версий
• Делать удаление определенных файлов, которые не должны быть включены в сборки / выпуски
• Выпускает код в папки развертывания
• Zips код для резервного копирования
• Развертывание служб Windows; начать и остановить их
• И т.п.

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

В последнее время я был недоволен NAnt по нескольким причинам: (1) его синтаксис просто ужасен - языки программирования поверх XML действительно ужасны, (2) проект, похоже, умер на корню; в последнее время не было тонны обновлений, и кажется, что никто не стоит у руля. Попытка заставить его работать с .NET 4 вызывает некоторые болевые точки из-за этого отсутствия активности.

Итак, со всем этим фоном, вот мой вопрос. Учитывая некоторые вещи, которые я хочу выполнить, основываясь на этом списке выше, и учитывая, что я в основном нахожусь в магазине .NET, но мне также нужно создавать проекты не .NET, есть ли альтернатива NAnt, которую я должен рассмотреть переключается на?

На моем радаре есть такие вещи, как Powershell (с psake или без него ), MSBuild и rake . У всех этих есть свои плюсы и минусы. Например, является ли MSBuild достаточно мощным? Я помню, как использовал его много лет назад, и у него не было такой силы, как у NAnt. Действительно ли я хочу, чтобы моя команда изучала Ruby только для того, чтобы делать сборки с использованием rake? Является ли psake достаточно зрелым проектом, чтобы прикрепить мое портфолио? Является ли Powershell «слишком близко к металлу», и мне придется написать свою собственную библиотеку сборки, похожую на psake, чтобы использовать ее самостоятельно?

Есть ли другие инструменты, которые я должен рассмотреть? Если бы вы занимались поддержкой портфеля .NET значительной сложности, какой инструмент сборки вы бы выбрали? Чем сейчас занимается ваша команда?

Если вы уже используете TeamCity, вы сможете использовать его существующие функции для большинства из того, что вам нужно. Он изначально поддерживает создание файлов Visual Studio .sln, и если вам нужны дополнительные материалы для всех ваших проектов, вы можете изменить файлы .targets .NET Framework на своих компьютерах сборки, чтобы вам не приходилось изменять отдельные файлы csproj.

Он автоматически извлекает из Subversion zip-артефакты, позволяя вам контролировать, какие файлы считаются развертываемыми артефактами. В новой версии (6.0) также предусмотрено несколько этапов сборки, поэтому существует возможность развертывания артефактов в общей копии в xcopy.

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

Мы подходим к вещам как к трем различным видам деятельности: сборка, развертывание и установка Мы используем TFS для сервера сборки с несколькими обращениями к Powershell. Затем мы используем Powershell для выполнения всех частей Deploy и Install, которые являются довольно сложными и на нескольких серверах, как локальных, так и облачных. Я был очень счастлив изучать Powershell поверх MSBuild или другого инструмента. У меня также был хороший опыт работы с Visual Build в прошлом.

Взгляните на Хадсона и MSBuild в паре. Власть обеспечивается мощными возможностями MSBuild и плагинами Hudson .

Например, вы можете использовать hudson и запускать сценарии NAnt, пока не перейдете на MSBuild, а затем он также сможет запускать ваши сценарии MSBuild.

Конкретно обращаясь к вашим точкам:

• Subversion и Tagging
• MSBuild
• Заглянуть в AssemblyInfo попросили SO, но решение может быть не по вкусу
• MSBuild может легко удалять файлы
• «Разблокировать код в папках развертывания» - система сборки может пропустить этот шаг и автоматически развернуть его, используя несколько методов. Или вы можете FTP, если хотите.
• MSBuild может почтовый индекс
• Службы Windows, опять же MSBuild ваш друг здесь.

Я использую Automated Build Studio . Я хочу избавиться от этого.

Единственная причина, по которой я не переключаюсь на 100% MS Build или Team Foundation Build, заключается в том, что это потребует затрат на восстановление сценариев, которые отлично работают сегодня. Сценарии не сильно меняются ...

Однако для следующего продукта это будет Team Foundation Build без каких-либо колебаний по следующим основным причинам (их гораздо больше):

• Его легко развернуть (последняя версия: 2010)
• Он полностью интегрирован с Visual Studio и Team Foundation Server.
• Это становится стандартом, как MS Build
• Это бесплатно с Bizspark (для стартапов)

Поскольку вы также находитесь в .NET, я настоятельно рекомендую вам использовать TFB.

Если вы не можете подать заявку на Bizspark или не можете позволить себе приобрести лицензию, вы можете выбрать CruiseControl.NET + MS Build и несколько сценариев поддержки. В крупной коммунальной компании, в которой я работал, мы использовали CruiseControl.NET для создания, тестирования, развертывания и составления отчетов по всем нашим проектам. Включено автоматическое развертывание веб-сервиса.

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

В настоящее время я делаю то, что вы делаете (т.е. от сборки до упаковки к развертыванию), используя MSBuild (> 3000 строк сценариев). CI использует CruiseControl.Net, и я надеюсь, что в будущем я смогу перейти на TeamBuild. MSBuild громоздкий (программирование на XML), но он достаточно мощный, особенно для пакетной обработки и отслеживания зависимостей. Он активно поддерживается и улучшается в новых версиях .Net и является основой системы сборки в Visual Studio и TFS. Кроме того, файлы проектов visual studio на самом деле являются проектами MSBuild, и я могу подключиться к различным точкам расширения. Пакет расширения MSBuildимеет много дополнительных задач, и легко создавать свои собственные задачи программно. Предлагаю серьезно подумать MSBuild. В последнее время я также изучаю PowerShell и нахожу его легким для определенных задач, особенно на этапе развертывания, таких как установка и настройка сертификатов, IIS и т. Д.

Отредактируйте проект MSBuild в VisualStudio, так как он понимает синтаксис и дает вам intellisense. Вот некоторые другие хорошие утилиты, которые помогут с MSBuild.
MSBuild Launch Pad - Для расширений оболочки
MSBuild SideKicks - Графически редактируйте, выполняйте и отлаживайте сценарии.

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

Я настоятельно рекомендую TeamCity, он прост в настройке и настройке. MSBuild предпочтительнее NAnt по той простой причине, что все файлы проекта / решения в vs2008 / 2010 технически являются файлами MSBuild, но вы можете настроить TeamCity с помощью MSBuild или NAnt.

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

Вы рассматривали Гудзон ? Это может быть немного хлопотно, так как для работы требуется сервер приложений Java, но я думаю, что он может позволить вам использовать ваш текущий скрипт NAnt и основываться на нем, используя другие инструменты.