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

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

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

  • Обновление svn
  • msbuild > build_deploy_development_out_msbuild
  • ([xml] (svn info --xml)). info.entry.commit.revision + [ char] 13 + [char] 10 + (echo% date%% time%) > build_revision_number. HTML
  • $linenumber = Select-String build_deploy_development_out_msbuild -pattern "Build Failed" | Select-Object Linenumber
  • $smtp = New-Object System.Net.Mail.SMTPClient -ArgumentList localhost | if ($ linenumber > 0) $smtp.Send( "From: Email", "To: Email", "build failed", "build failed... кто-то должен умереть!" )

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

Затем я нырнул в buildbot и нашел его по-настоящему прекрасным. Через пару дней я установил в основном тот же процесс. Build script - это истинный объект python, который настраивается у мастера, откуда он передается ведомым и выполняется там. Построенный на скрученном каркасе, это много чего-то из коробки;)

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

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

Ответ 5

Ниже приводятся мои мысли о CI Server над сценариями Powershell

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

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