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

10

Я занимаюсь поддержкой довольно большого портфеля приложений .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, которую я должен рассмотреть переключается на?

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

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

RationalGeek
источник

Ответы:

2

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

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

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

Адам Лир
источник
3

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

Мэтт Макк
источник
2

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

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

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

  • Subversion и Tagging
  • MSBuild
  • Заглянуть в AssemblyInfo попросили SO, но решение может быть не по вкусу
  • MSBuild может легко удалять файлы
  • «Разблокировать код в папках развертывания» - система сборки может пропустить этот шаг и автоматически развернуть его, используя несколько методов. Или вы можете FTP, если хотите.
  • MSBuild может почтовый индекс
  • Службы Windows, опять же MSBuild ваш друг здесь.
Стивен Эверс
источник
Спасибо за информацию о MSBuild. Кажется, там больше энергии, чем в прошлый раз, когда я пытался ее использовать. Что касается Hudson, дает ли это преимущество помимо того, что предоставляют другие CI-серверы, такие как TeamCity, который мы в настоящее время используем? Я стараюсь не нарушать слишком много статус-кво здесь, и замена нашего CI-сервера в то же время, когда мы заменяем наши сценарии сборки, кажется более болезненной.
RationalGeek
По моему скромному мнению, я считаю, что TeamCity - это фантастика ... а Хадсон - лучше. Видно, что они выполняют те же функции, пока вы не захотите сделать что-то потрясающее - тогда победит Хадсон. Честно говоря, Hudson может анализировать (stylecop / fxcop) -> build-> test-> tag-> local и offsite backup -> deploy, поддерживая вас в курсе событий через RSS, SMS, XFD.
Стивен Эверс
Хм ... в этом списке нет ничего невозможного с TeamCity, но, возможно, с Хадсоном это проще. В любом случае, если мы не достигнем некоторых болевых точек с TC, я не думаю, что мы переключимся в ближайшее время.
RationalGeek
@jkohlhepp: Сложность в том, что в одном и том же пространстве есть много разных решений. В конце концов, Гудзон является легким и 100% бесплатно. IIRC, одна вещь, которую TC может иметь в отношении Hudson, - это построение нескольких агентов.
Стивен Эверс
2

Я использую 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 для создания, тестирования, развертывания и составления отчетов по всем нашим проектам. Включено автоматическое развертывание веб-сервиса.


источник
Я не рассматривал этот вариант, но не думаю, что он будет для нас реалистичным, поскольку мы вообще не используем TFS и наложили вето на попытки перейти к нему в прошлом (по бюджету и по другим причинам). Но спасибо за предложение, которое является интересной идеей.
RationalGeek
Это не так уж и много. Если ваше управление чувствительно к цене, MS Build будет идеальным выбором. Раньше я работал только с MS Build + CruiseControl.NET, и он работал отлично! Добавлю, что в моем ответе.
@Pierre 303: Ради любопытства, почему вы хотите избавиться от Automated Build Studio?
RationalGeek
@Pierre 303: расходы TFS не единственная проблема. Мой магазин является частью более крупного предприятия, и они стандартизированы на Subversion и других инструментах, и потому что они «нестандартны», а переход на TFS вызывает политические проблемы.
RationalGeek
@jkohlhepp: его нелегко использовать, он плохо интегрирован с Visual Studio (по крайней мере, у меня есть версия) и далеко не является стандартом.
2

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

Matt
источник
2

В настоящее время я делаю то, что вы делаете (т.е. от сборки до упаковки к развертыванию), используя 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 - Графически редактируйте, выполняйте и отлаживайте сценарии.

softveda
источник
1

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

Уайетт Барнетт
источник
Кажется, что большинство из этих ответов приравнивают CI к сценариям сборки. Я всегда считал, что сценарии сборки являются умными, а CI-сервер - тем, что запускает сборки на основе триггеров. Но, возможно, вы правы, и мне нужно переосмыслить это.
RationalGeek
1

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

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

Срикант Ремани
источник
1
FYI TeamCity бесплатен, если у вас менее 20 конфигураций сборки и менее 20 пользователей. Кроме того, если вы являетесь проектом с открытым исходным кодом, вы можете обратиться к ним за бесплатной неограниченной лицензией.
RationalGeek
0

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

MCHL
источник
Hudson - это скорее платформа непрерывной интеграции, а не платформа для сборки. У нас есть CI-сервер - TeamCity, который отлично работает с NAnt. Однако причины, по которым я хочу заменить NAnt, состоят в том, что поддержка сценариев NAnt является болезненной. Использование текущих сценариев через Hudson не решает эту проблему. Спасибо за предложение, хотя.
RationalGeek
ИМХО Хадсон очень ограничен в том, что он делает правильно с проектами VS. Оформление заказа не привязано к наборам изменений так, как вы ожидаете, и за кулисами ничего не делает, кроме запуска пакетного файла, который вы создаете через веб-интерфейс, и множества плагинов. Отчетность это довольно приятно, если вы можете заставить его работать хорошо, хотя.
Билл