Jenkins - продвижение сборки в разные среды - PullRequest
Новая
       22

Jenkins - продвижение сборки в разные среды

8 голосов
/ 21 июля 2011

Я надеялся получить несколько советов о том, как наилучшим образом продвигать сборку в ее среде.

У нас есть 3 среды: DEV, STAGING, PROD.

Сборка DEV Jenkins выполняется в режиме непрерывной интеграции, поскольку код возвращается в subversion, Jenkins запускает новую сборку (очистить, скомпилировать, протестировать, развернуть).

Сложность в том, что касается STAGING и PROD.

Идея состояла в том, чтобы иметь возможность вручную продвигать успешную сборку DEV в STAGING. Сборка STAGING будет проверять номер версии SVN DEV, создавать, тестировать, развертывать в промежуточную и, наконец, создавать ветку в SVN.

Наконец, менеджер релизов может вручную продвигать сборку STAGING в PROD. Сборка PROD извлекает ветку из предыдущей сборки STAGING, развертывает в PROD и помечает ветку как релиз.

Я пытался использовать комбинацию плагина Promotion Builds и плагина Paramterized Trigger, но безуспешно. Кажется, номер редакции Subversion не передается между сборкой DEV в сборку STAGING.

Есть ли у кого-нибудь какие-либо рекомендации относительно их процесса продвижения сборки в нескольких средах?

Ответы [ 3 ]

3 голосов
/ 13 сентября 2011

Другой подход заключается в использовании хранилища артефактов, которое Jenkins предоставляет в сочетании с плагином копирования артефактов .

  1. Когда сборка будет завершена, вы можете указать Jenkins сохранить вашприложение, либо в виде сжатого zip / tar.gz, либо в виде пакета приложения (jar / war)
  2. Запустите последующее задание и используйте артефакт копирования, чтобы извлечь записанный артефакт из вышестоящего задания (или использовать параметризованные сборки)
  3. Развертывание / распаковка артефакта по мере необходимости - Создание сценария оболочки / развертывание maven?
  4. Повторное тестирование приложения с использованием тех же исходных / двоичных файлов, которые были созданы на шаге 1
  5. Повторите для PRODпри необходимости

Этот подход позволил бы вам выявить артефакты и, таким образом, Дженкинс связал бы сборки в пользовательском интерфейсе, а также разрешил бы более формальное отключение.

2 голосов
/ 22 июля 2011

В этом случае зачем вам возвращаться и маркировать ветку в svn? Мы не используем SVN, но с TFS, когда Хадсон / Дженкинс получает код, номер полученной им ревизии находится в журнале сборки. Итак, мы знаем, из какого кода пришла сборка, и можем вернуться к нему в любое время.

Затем мы продвигаем сборку из среды в среду, используя Hudson, системе контроля версий не нужно знать, где развернут код.

0 голосов
/ 13 сентября 2011

Если абсолютно необходимо сохранить идентификатор редакции SVN, добавьте шаг сборки в задание DEV, которое скопирует его в файл.Примерно так: 

echo %SVN_REVISION%>revision.ini

или что-то вроде этого: 

echo MY_SVN_REVISION=%SVN_REVISION%>revision.ini

Тогда артефакт revision.ini.При выполнении сборки STAGING используйте плагин Copy Artifact (как упоминалось предыдущим пользователем), чтобы получить файл revision.ini, специфичный для сборки, и загрузить его в переменную.Затем используйте эту переменную в вызове командной строки для "svn", чтобы построить тег.

...