Рабочий процесс для jenkins

Question

Я отвечаю за реализацию CI в своей компании. Но теперь у меня есть сомнения. Какой из них лучше?

Должен ли я создать 3 уважаемую работу для каждой системы/программное обеспечение как

1. построения и тестирования качества для кода
2. сборки, проверки качества и развертывания на тестовом enviromment
3. сборки, качество испытаний и развертывания по производству

Или лучше создать нижестоящие условные рабочие места, как здесь: How to conditionally build other projects?

В багажнике всегда будет установлена ​​последняя версия.

Для каждого изменения разработчик должен сделать копию с соединительной линии на ветку, работать над кодом, а затем вызвать jenkins для запуска в ветке для омологации изменений. Как только омологация сделала, и все в порядке, разработчик снова вызовет jenkins, чтобы развернуть этот код из ветки в производство.

Как @michaelbahr сказал [это сообщение редактируются] я могу просто получить последнюю версию омологации из хранилища артефактов, но как я могу скопировать/объединить код из ветви автоматически хобот с Дженкинс после того, как получает пакет из среды омологации (тестирования) и переместить его в производство?

Answer 1

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

Первое задание должно автоматически запускаться при внесении изменений в репозиторий кода через крюк после фиксации. Он создает, тестирует и развертывает пакет в тестовой среде. Он должен также развернуть пакет моментальных снимков в хранилище артефактов, как Nexus.

Если вы все довольны результатами, вы можете вручную запустить второе задание, которое захватывает пакет из хранилища артефактов и развертывает его для производства (и проверяет, что развертывание было успешным). Нет необходимости в создании пакета снова, в котором вы уже уверены.

Answer 2

Какой подход лучше всего зависит от качества вашей техники, тестов и процессов. Один из подходов - это сделать все три в одной работе (которая может при необходимости привязать другие задания).

Например:

Использование MultiJob Plugin и Validated Merge Plugin рабочий процесс выглядит так:

1. Разработчик толкает код Дженкинс (мерзавца толчке), а не репо SCM.
2. Jenkins строит код, запускает модульные тесты и делает результаты доступными локально - или лучше в репозитории.
3. Выполнение дополнительных заданий (по порядку) до Установка и запуск встроенных тестов кода и интеграции в среде интеграции. Обратите внимание, что при тестировании плагинов Multi Job можно запускать параллельно во многих средах одновременно.После успеха всех тестовых заданий валидированное слияние принимает изменения в репозитории. (Если ошибка, изменения разработчика не добавляются в репозиторий).
4. Другая последующая работа принимает успешные результаты и развертывается на производстве.
5. Задание интеграции может быть использовано для сброса среды интеграции.

Обратите внимание, что наличие отдельного задания для развертывания на производстве также допускает повторное развертывание в любой момент времени. Развертывание производства также может быть отделено от автоматизации, если оно считается подозрительным.

И, наконец, обратите внимание, что недостаточный уровень точности или полноты тестирования делает опасно неустойчивую систему!