Автоматизированные выпуски с Hudson + Ant + Subversion

Question

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

1. Ветвь для строки релиза.Как только наша линия развития стабилизируется, мы бы хотели перейти.Поскольку у нас есть пользователи с низкой плотностью и высоким спросом, после официального релиза часто наблюдается небольшой всплеск активности, что приводит к некоторой остановке разработки в начале строки релиза (а мы недля этого нужно заблокировать разработку магистрали), поэтому практика ветвления в удобное время, а затем с учетом стабилизационного окна (от часа до дня или двух) имеет смысл.(Это делается в Subversion; обычно мы помечаем релиз разработки непосредственно перед веткой, затем ветвью, затем продолжаем параллельную разработку)

2. Вырезать релиз из ветви.В настоящее время это включает в себя

   1. Немного "исправления", чтобы поставить номера релизов там, где они принадлежат.
   2. Регистрация
   3. Метка
   4. Экспорт
   5. Build
   6. Немного исправлений для возврата номеров релизов в "devel / snapshot".
   7. Checkin

ИтакЧисто, чтобы реализовать что-то подобное в Hudson, как мы можем:

• Выполнить операцию ветвления из Hudson, которая разветвляет дерево, учитывая новое имя ветки выпуска, и порождает новое задание Hudsonсоздать новую непрерывную линию сборки для этой ветви.(Он близок к копии существующей конфигурации -trunk, но должен заменить некоторые имена и другие элементы рабочего пространства ...)

• Куда относится логика для взаимодействия с Subversion?(Возможно, может быть в скрипте муравья; может быть отдельным скриптом; кажется, что Хадсон / плагины также предоставляют некоторую эту логику?)

• Любые мысли о пользователях / разрешениях для Хадсона /вспомогательные процессы, когда он разговаривает с репо в режиме записи?

• Как насчет второго этапа, также применимы вышеуказанные вопросы, могу ли я просто использовать плагин релиза для автоматизации такой логики?

Я пролистал документацию по Hudson и Release Plugin, но она довольно неаккуратная, и не было много проработанных примеров, выложенных из конца в конец ...

Отредактировано, чтобы добавить: Я понимаю и ожидал, "Вы рассматривали Maven?"Ответы ... Я ценю это, и я понимаю, что Maven, вероятно, является правильным долгосрочным решением, но изменение системы сборки вместе со всеми усилиями и опасностями перехода к точным ограничениям Maven и обучения технического персонала не представляется возможнымв ближайшее время.Предположительно, есть способ сделать это с помощью муравья и небольшого количества смазки для локтя ...

Answer 1

Это решение предназначено, пока вы не поставите Maven на место.

Я думаю, вам нужно просто создать несколько скриптов, чтобы выполнить всю работу (скрипты ant и / или batch / shell). Взгляните на плагин Batch Task . Это позволяет вам запускать выпуск поверх текущей рабочей области вашей работы. Ваши сценарии предназначены для выполнения всей работы. Вы можете настроить копию вашей текущей работы, используя remote api . Если переменные среды, такие как JobName, недоступны, вам, вероятно, потребуется жестко указать имя задания (или записать их во время сборки в файл в рабочей области). В конце у вас будет обновленный ствол (строка dev), новая строка релиза (в ветвях) и задание, которое запускает весь ваш CI в ветке релиза.

Answer 2

Краткосрочный процесс на основе Ant

Учитывая вашу приверженность процессу сборки Ant (и в этом нет ничего плохого, кроме положительных моментов, которые вы упускаете), я бы предложилчто вы отражаете подход Maven, но делаете это в Ant.Поэтому внимательно прочитайте эту статью , в которой показано, как использовать SVNAnt .

Идеальное решение для долгосрочной перспективы

Как упоминал @Peter LawrayМэйвен твой друг здесь.В частности, обратите внимание на плагин релиза, который будет управлять процессом пометки вашего хранилища Subversion версией вашего проекта «золотой релиз».По сути, вы выполняете полную сборку (включая функциональные тесты, если они у вас есть), чтобы проверить свой артефакт, затем Maven помечает ваш репозиторий Subversion и, наконец, он запускает файлы вашего проекта pom.xml и переопределяет их на следующий уровеньup (в виде моментальных снимков).

С точки зрения процесса сборки, Hudson весело работает с Maven и будет собирать и тестировать артефакты (ваши JAR, WAR, EAR и т. д.) в последовательности, указанной вами в Maven pom.xml.

При желании вы можете связать SeleniumRC и предоставить среду автоматизированного функционального тестирования с несколькими браузерами.Maven обрабатывает все это от сборки до развертывания артефакта на сервере сборки и последующего функционального тестирования с окончательным завершением процесса выпуска.

Я немного об этом написал в блоге если вам интересно.

Answer 3

Я бы не делал ветвления и пометки как часть сборки, я делал бы это вручную. Это (опять!), Возможно, философское различие: я вижу Хадсона как способ взять текущее состояние некоторой строки кода и произвести ее артефакты, а не как инструмент для манипулирования строками кода. Это как большой компилятор, но не как в IDE.

Итак, мой процесс будет выглядеть (а наш процесс действительно выглядит):

1. Метка в точке выпуска (назовите ее root_release23_20101124)
2. Ветвь в этой точке (назовите это release23_20101124)
3. Отредактируйте файлы свойств релиза, добавив номер релиза, и сделайте любое другое исправление
4. Заезд в филиал
5. Настройте новое задание Hudson (скопировав задание шаблона) для создания выпуска, настроив его для извлечения из ветви
6. Выполнить задание

Итак, настройка нового выпуска является задачей разработчика / менеджера сборки, но на самом деле сборка релиза выполняется Хадсоном.

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