Настройка Hudson для развертывания сборки - PullRequest
Новая
       13

Настройка Hudson для развертывания сборки

8 голосов
/ 06 января 2011

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

Я пытался использовать плагин развертывания для автоматического развертывания файла .war, и это работает.Однако задание, которое создает файл .war, будет запускаться после каждого изменения scm (всякий раз, когда код фиксируется).С помощью плагина развертывания .war-файл будет развертываться в Tomcat каждый раз, когда выполняется сборка.Поскольку код передается часто, это будет означать, что веб-приложение будет также часто перезапускаться, и это будет прерывать процесс тестирования.

Я ценю тот факт, что Hudson запускает мои юнит-тесты и регулярно выполняет сборку.поэтому я не хочу менять триггеры для этой работы.

Я ищу способ, которым я могу вручную принять решение о развертывании из Хадсона.Я попытался создать отдельное задание, которое будет развертывать .war из первого задания, но это не сработало.У кого-нибудь есть опыт настройки чего-то подобного?

Ответы [ 2 ]

7 голосов
/ 06 января 2011

Как достать артефакты

Посмотрите раздел " Как откатить или повторно развернуть предыдущую сборку " на странице Deploy Plugin . Это описывает основную идею. Он использует Плагин копирования артефактов для копирования артефактов из задания сборки в ваше текущее задание (задание развертывания). Оттуда вы делаете то же самое, что и на этапе сборки.

Как запустить развертывание

Задание сборки не может быть запущено после запуска развертывания, поэтому сначала выполняется сборка, а затем задание развертывания. Так что есть несколько вариантов:

  • вручную вызвать сборку. Пользователь, запускающий развертывание, должен выбрать определенный запуск задания сборки.
  • запланированное развертывание Это может быть частью ночных задач. Работа запускается через определенный промежуток времени (например, каждую ночь или каждые выходные). Поскольку это автоматизировано, задание развертывания должно выбрать последнюю успешную сборку (тогда вам не нужно параметризованное задание). У вас нет возможности передать номер прогона.
  • задание на развертывание запускается при каждом успешном завершении сборки (не соответствует вашим требованиям, но указано в списке для завершения списка)
  • Некоторые другие (эзотерические) триггеры . Это может быть много разных думает, например, удаленно вызывается путем вызова URL сборки. Вызов может поступить от одной из ваших систем продажи билетов, системы управления тестовой лабораторией или любой другой системы, которая вам нравится. Вы также можете инициировать развертывание с помощью конкретных изменений в вашей системе управления версиями, таких как изменение номера выпуска (например, отмеченного ключевым словом в сообщении о фиксации). Этот триггер может быть реализован внутри или за пределами Гудзона. Есть и другие доступные триггеры. Это включает, но не ограничивается изменением HTML-страницы, изменением отслеживаемой части файловой системы, IM-сообщением, электронной почтой. Первые три реализованы плагином Hudson. Посмотрите на список плагинов, чтобы узнать, что все доступно или в обоих случаях необходимо убедиться, что задание на сборку архивирует все артефакты, необходимые для развертывания.
1 голос
/ 06 января 2011

У меня есть несколько заданий hudson для каждого проекта:

  1. Основная задача, которая просто собирает проект и запускает тесты.В случае успеха запускаются следующие задания:
  2. Задание метрики кода (PMD, FindBugs, Cobertura, CheckStyle, также генерация JavaDoc) и
  3. Задание развертывания, которое создает проект с использованием mvn package -DskipTests и разворачивает войну с котом

Я считаю, что при разделении этих упрощенных вещей только первая работа прислушивается к изменениям SCM.

Однако другим способом было бы позволить третьемуРабота также слушать SCM (но с более длительным интервалом, возможно, час).

...