Непрерывная интеграция: PowerShell против CI Server (CC.NET или Hudson)

Question

Итак, мы с другом обсуждали непрерывную интеграцию и сценарии bat / powershell против серверов CI, таких как CruiseControl.Net или Hudson.

Следующий псевдокрипт powershell предназначен для обновления из SVN, сборки с использованием msbuild, развертывания / копирования, обновления номера сборки / ревизии в приложении и отправки по электронной почте неудачных сборок. Следующим шагом будет добавление вызовов в MSTest и результатов электронной почты, если они не будут успешными.

1. svn update
2. msbuild> build_deploy_development_out_msbuild
3. ([xml] (svn info --xml)). Info.entry.commit.revision + [char] 13 + [char] 10 + (echo% date%% time%)> build_revision_number.html
4. $ linenumber = Select-String build_deploy_development_out_msbuild -pattern "Ошибка сборки" | Номер объекта Select-Object
5. $ smtp = New-Object System.Net.Mail.SMTPClient -ArgumentList localhost | if ($ linenumber> 0) $ smtp.Send ("From: Email", "To: Email", "build build failed", "сборка не удалась ... кто-то должен умереть!")

Это привело меня к вопросу о ценности серверов CI, когда вы можете написать свои собственные сценарии оболочки для достижения той же цели, используя специальные инструменты проекта (инструмент сборки, управление исходным кодом, модульное тестирование) (т.е. msbuild, nant, svn, git, nunit, mstest и т. д.)

У меня еще не было затрат на обслуживание. Я хотел узнать мнение других о том, как создать собственный сценарий оболочки, а не CruiseControl.Net или Hudson. Обратите внимание, что у меня нет опыта работы с серверами CI, поэтому вопрос, поэтому, пожалуйста, не принимайте это как критичный для серверов CI; Я просто не знаю лучшего ответа и решил спросить у сообщества.

С наилучшими пожеланиями! Пит Гордон

Answer 1

CI-серверов дают вам несколько преимуществ:

• веб-доступ, обычно с возможностью интеграции с существующими механизмами аутентификации (см. Поддержку ActiveDirectory / LDAP от Hudson)
• Тонны существующей поддержки модульного тестирования, создания zip-архивов и т. Д.
• Hudson (и другие) поддерживает подчиненные узлы сборки для выполнения задач распределенного CI.
• Не нужно поддерживать это самостоятельно.

Возможно, некоторые из этих вещей вам не нужны сейчас но вы уверены, что это не то, что вам может понадобиться в будущем?

Answer 2

... или есть оба. Ayende (создатель Rhino Mocks) сделал это недавно. Он написал CI-сервер, используя PowerShell. Возможно, это предоставит новые возможности для обсуждения.

Answer 3

Я установил Hudson пару недель назад, чтобы заменить текущий сервер CruiseControl. Наибольшее преимущество, которое я вижу в Hudson, заключается в том, что его может использовать почти каждый, хотя запуск параметризованной сборки с помощью CruiseControl (или пакетного файла) все еще пугает многих.

Обычно я пишу все свои сценарии сборки с помощью Ant (потому что он переносимый), вставляю пару параметров и вызываю их из Hudson.

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

Answer 4

Ниже мои мысли о CI Server через сценарии Powershell

• Настраиваемые Плагины доступны для всех видов контроля версий, уведомлений и тестирования.
• Журналы Они прекрасно поддерживаются. Журнал неудачных и успешных сборок у вас под рукой.
• Планирование Вы можете установить все виды планирования, включая запуск, на основе других успешных сборок
• Безопасность Вы можете настроить разные группы для выполнения, просмотра или настройки для просмотра некоторых проектов
• Видимость Вы можете использовать веб-панель управления или cctray для разных аудиторий.
• Масштабируемость . Легко масштабируется при необходимости.

Итог: если вам нужно поддерживать множество сборок для разных сред и командных проектов, то CI Server - это то, что вам нужно. Кроме этого, для небольших проектов достаточно простого скрипта PowerShell. По мере роста проекта вы можете просто подключить существующий сценарий PowerShell к CI-серверу.

Answer 5

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

Потом я погрузился в buildbot и нашел его действительно красивым. Я настроил в основном тот же процесс за пару дней. Сценарий сборки - это настоящий объект Python, который настраивается на главном сервере, откуда он передается подчиненным и исполняется там. Построен на витой платформе, это много вещей из коробки;)

Веб-интерфейс минималистичен, хотя и достаточен.

Ну, это тоже неопубликовано, хотя на этот раз я близок к этому%)