Непрерывная интеграция: 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.