Релиз с Maven, SVN и Hudson (Дженкинс)

Question

Я хотел бы сделать «релиз», который немного отличается от того, который предполагает плагин релиза Maven.

У меня есть веб-проект (который я хотел бы «выпустить»), который зависит от различных других проектов, которые также создаются одним и тем же Hudson (но не как модули).

«Релиз» должен делать следующее:

• сборка всех зависимых ^ зависимых проектов через hudson
• сборка веб-проекта (добавление увеличивающегося номера версии в MANIFEST)
• развернуть веб-проект на tomcat (это уже в обычной сборке)
• создать новый тег, который включает номер версии в местоположении svn x
• скопировать все текущие svn / head-источники проектов, которые ранее были собраны, в новый тег
• изменить все pom-версии всех вовлеченных проектов на $ {versionNumber} .0.1-SNAPSHOT в SVN / head

Я полагаю, что это то, что каждый должен делать, просто очень трудно найти реальное решение через Google.

Answer 1

Звучит так же, как наши требования.Мы еще не полностью реализовали это в Дженкинсе.

Итак, у нас есть следующая процедура:

1. объявить замораживание кода, чтобы все команды имели «правильный» кодв магистрали и иметь код в «синхронизации» друг с другом.

2. Мы запускаем (доморощенный) Java-инструмент, который проверяет код создает ветви для выпуска и выпускатеги.начиная следующую итерацию, он также обновит транк с новой версией снимка.У инструмента есть свои собственные файлы конфигурации, так что он знает, какие номера версий / будут и какие проекты (и где они расположены) должны быть обновлены.

3. Мы запускаем наш 'сборка релиза ', которая в значительной степени отключена от всех наших внутренних корпоративных репо (она знает только о сторонних и внешних репо).Задание очищает локальный репозиторий Maven (у него есть собственный репо, который не используется другими заданиями).Я загружаю все подпапки, относящиеся ко всем нашим проектам (нам необходимо настроить это в работе), используя для каждого из них параметр subversion-tag-tag и дополнительный pom-проект Mega, который объявляет все загруженные проекты как модули (необходимо перейти в корневую папку),Эта работа также выполняет всю необходимую упаковку (архивирование статического содержимого, объединение статических файлов из разных проектов в один архив, ...).

4. развертывание

5. функциональное тестирование

Пока у 2 есть своя собственная работа, а у 3 полностью автоматизирована, нам просто нужно запустить ее вручную.Шаг 4 находится в работе для CI, и Шаг 5 запланирован для CI.Шаг 4 является горячим кандидатом для автоматизации (даже если он только по частям) процесса выпуска.

Надеюсь, это немного поможет и даст вам несколько идей.

Answer 2

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