Я занимаюсь поддержкой довольно большого портфеля приложений .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 значительной сложности, какой инструмент сборки вы бы выбрали? Чем сейчас занимается ваша команда?
источник
Я использую Automated Build Studio . Я хочу избавиться от этого.
Единственная причина, по которой я не переключаюсь на 100% MS Build или Team Foundation Build, заключается в том, что это потребует затрат на восстановление сценариев, которые отлично работают сегодня. Сценарии не сильно меняются ...
Однако для следующего продукта это будет Team Foundation Build без каких-либо колебаний по следующим основным причинам (их гораздо больше):
Поскольку вы также находитесь в .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 и основываться на нем, используя другие инструменты.
источник