Если вы ищете автоматизированный «Pull Request» или конвейер Jenkins CI/CD на основе ветвей, это руководство поможет вам получить четкое представление о том, как это сделать с помощью многоветвевых конвейеров Jenkins. Многоветвевой конвейер Jenkins — один из лучших способов разработки рабочего процесса CI/CD, поскольку он полностью основан на git в виде кода. В этом руководстве я рассмотрю все ключевые концепции, связанные с настройкой многоветвевого конвейера Jenkins.
Начнем с основ многоветвевого конвейера. В частности, в этом разделе я опишу, что такое многоветвевой конвейер и почему его использование важно для всех конвейеров Jenkins CI/CD. Я также покажу вам, как работают конвейеры с несколькими ветвями, с подробными схемами рабочих процессов.
Многоветвевой конвейер — это концепция автоматического создания конвейера Jenkins на основе ветвей Git. Это означает, что он может автоматически обнаруживать новые ветки Git по мере их создания в SCM (Github) и автоматически создавать конвейер для этой ветки. Когда сборка конвейера запускается, Jenkins использует Jenkinsfile в этой ветке для этапа сборки.
SCM может быть репозиторием Github, Bitbucket или Gitlab.
Если вы не хотите, чтобы выбранная ветвь отображалась в автоматическом конвейере с регулярными выражениями Java, вы можете исключить ее. Конвейеры с несколькими ветвями поддерживают обнаружение ветвей на основе PR. Это означает, что если кто-то сделает PR (pull request) из ветки, ветка будет автоматически обнаружена в пайплайне. Если эта конфигурация включена, сборка будет запускаться только при повышении PR. Так что, если вы ищете рабочий процесс сборки Jenkins на основе PR, это хороший выбор.
Вы можете добавить условную логику в Jenkinsfile для создания заданий на основе требований ветки. Например, если вы хотите, чтобы ваша функциональная ветвь выполняла только модульные тесты и анализ Sonar, вы можете установить условие, чтобы пропустить фазу развертывания, используя условие, как показано ниже.
Таким образом, всякий раз, когда разработчик отправляет PR из функциональной ветки в другую, конвейер запускает этапы модульного тестирования и анализа Sonar, пропуская этап развертывания. Кроме того, конвейеры с несколькими ветвями не ограничиваются приложениями с непрерывной доставкой. Вы также можете использовать его для управления кодом инфраструктуры.
Как работают многофилиальные пайплайны?
Я проведу вас через базовый рабочий процесс сборки и развертывания, чтобы понять, как работают многоветвевые конвейеры.
Допустим, я хочу, чтобы конвейер Jenkins создавал и развертывал приложение при следующих условиях.
-
Разработчики начинают с ветвей функций, фиксируя в них код.
-
Всякий раз, когда разработчик извлекает PR из функциональной ветки для разработки ветки, конвейер Jenkins должен запускать модульные тесты и статический анализ кода.
-
После успешного тестирования кода в функциональной ветке разработчик объединяет PR в ветку разработки.
-
Когда код готов к выпуску, разработчик поднимает PR из ветки разработки в мастер. Он должен запускать конвейер сборки, который будет запускать модульные тесты, анализировать код и развертывать в среде разработки/контроля качества.
Как вы можете видеть из приведенных выше условий, ручной запуск заданий Jenkins невозможен, и всякий раз, когда есть запрос на ветку, конвейер должен запускаться автоматически и выполнять необходимые шаги для этой ветки. Этот рабочий процесс создает отличный цикл обратной связи для инженеров и позволяет не полагаться на команды DevOps для создания и развертывания в непроизводственных средах. Разработчики могут проверить статус сборки на Github и решить, что делать дальше.
Этот рабочий процесс легко достигается с помощью многоветвевых конвейеров Jenkins. На изображении ниже показано, как будет выглядеть рабочий процесс конвейера с несколькими ветвями для приведенного выше примера процесса сборки.
Так работают многоветвевые пайплайны.
-
Когда разработчик создает PR из функциональной ветки для разработки ветки, Github отправляет Jenkins веб-перехватчик с информацией о PR.
-
Дженкинс получает PR, находит соответствующий многоветвевой конвейер и автоматически создает ответвленный конвейер. Затем он запускает задание, следуя шагам, указанным в файле Jenkins в ветке функций. Во время проверки исходная и целевая ветки в PR объединяются. Слияние PR будет заблокировано на Github до тех пор, пока Jenkins не вернет статус сборки.
-
После завершения сборки Дженкинс обновит статус до Github PR. Теперь вы сможете объединить код. Кроме того, если вы хотите просмотреть журнал сборки Jenkins, вы можете найти ссылку на журнал сборки Jenkins под статусом PR.
Многоветвевой конвейер Jenkinsfile
Прежде чем приступить к реализации, давайте рассмотрим пример Jenkinsfile для многоветвевого конвейера Jenkins, который можно использовать в конвейере.
Чтобы конвейеры с несколькими ветвями работали, вам необходимо иметь Jenkinsfile в вашем репозитории SCM.
Если вы изучаете/тестируете, вы можете использовать многоветвевой конвейер Jenkinsfile, указанный ниже. Он имеет этап проверки и другие этапы, которые повторяют сообщения.
Кроме того, вы можете клонировать и использовать репозиторий Github с этим Jenkinsfile.
ПРИМЕЧАНИЕ . Замените метку агента «мастер» своим именем агента Jenkins. master тоже будет работать, но не рекомендуется запускать его в реальной среде проекта.
трубопровод {
агент {
узел {
ярлык «мастер»
}
}
параметры {
buildDiscarder logRotator(
daysToKeepStr: '16',
numToKeepStr: '10'
)
}
этапы {
stage('Очистка рабочей области') {
шаги {
очиститьWs()
ш """
echo "Очищено рабочее пространство для проекта"
"""
}
}
stage('Проверка кода') {
шаги {
проверить([
$класс: 'GitSCM',
ветки: [[имя: '*/main']],
userRemoteConfigs: [[url: 'https://github.com/spring-projects/spring-petclinic.git']]
])
}
}
этап(' Модульное тестирование') {
шаги {
ш """
echo "Выполнение модульных тестов"
"""
}
}
этап('Анализ кода') {
шаги {
ш """
echo "Анализ выполняемого кода"
"""
}
}
stage('Собрать код развертывания') {
когда {
ветка "развивать"
}
шаги {
ш """
echo "Создание артефакта"
"""
ш """
echo "Развертывание кода"
"""
}
}
}
}
Настройка многоветвевого конвейера Jenkins
Здесь я покажу вам шаг за шагом, как настроить многоветвевой конвейер на Jenkins. Установка будет основана на Github и последней версии Jenkins 2.x. Вы также можете использовать Bitbucket или Gitlab в качестве источника SCM для многоветвевых конвейеров.
Шаг 1: Создайте «Новый проект» на домашней странице Jenkins.
Шаг 2: Выберите Multi-Branch Pipeline из вариантов и нажмите OK.
Шаг 3: Нажмите «Добавить источник» и выберите Github.
Шаг 4. В поле «Аутентификация» выберите Jenkins и создайте аутентификацию, используя свое имя пользователя и пароль Github.
Шаг 5: Выберите созданные учетные данные и укажите свой репозиторий Github для проверки учетных данных, как показано ниже.
Если вы тестируете многоветвевой конвейер, вы можете клонировать демо-репозиторий Github и использовать его. https://github.com/devopscube/multibranch-pipeline-demo.
Шаг 6: Выберите нужный вариант в соответствии с вашими требованиями. Вы можете открыть все ветки в репозитории или только те, которые содержат запросы на вытягивание.
Конвейеры также могут обнаруживать ветки с PR из разветвленных репозиториев.
Выбор этих параметров зависит от желаемого рабочего процесса.
Вы можете выбрать дополнительные варианты поведения с помощью кнопки «Добавить».
Например, если вы решите не обнаруживать все ветки в репозитории, вы можете выбрать регулярное выражение или метод подстановочных знаков для обнаружения веток в репозитории, как показано ниже.
Вот пример регулярного выражения и подстановочного знака.
Шаг 7: Если вы решите использовать другое имя для вашего Jenkinsfile, вы можете сделать это, указав имя в конфигурации сборки. В опции «Путь к сценарию» вы можете указать желаемое имя. Убедитесь, что у вас есть Jenkinsfile в репозитории с тем же именем, которое вы указали в конфигурации конвейера.
Кроме того, включите «Отменить старые версии», чтобы сохранить только необходимые журналы сборки, как показано ниже.
Шаг 8: Сохраните все конфигурации задания. Дженкинс сканирует настроенный репозиторий Github на наличие всех веток с поднятыми PR.
На изображении ниже показано задание, которое сканирует три ветки, и, поскольку я не делал запросов на вытягивание, Дженкинс не будет создавать конвейеры на основе веток. Я покажу, как протестировать автоматическое создание пайплайна после настройки вебхука.
Пока что мы настроили Jenkins для сканирования веток на основе PR-запросов. Чтобы иметь полный рабочий процесс, нам нужно настроить веб-хук в Github для отправки всех событий (коммитов, PR и т. д.) в Jenkins, поскольку конвейеры могут запускаться автоматически.
Настройка веб-перехватчиков для конвейеров с несколькими ветвями
Выполните следующие действия, чтобы настроить веб-перехватчик Jenkins в репозитории.
Шаг 1: Перейдите в репозиторий Github и нажмите «Настройки».
Шаг 2: Выберите параметр веб-перехватчика слева и нажмите кнопку «Добавить веб-перехватчик».
Шаг 3: Добавьте URL-адрес Jenkins, а затем «/github-webhook/» в разделе URL-адрес полезной нагрузки. Выберите тип контента «application/json» и нажмите «Добавить веб-перехватчик».
Примечание. Вы можете выбрать тип веб-перехватчика, который хотите получать в Jenkins. Например, вы хотите запустить конвейер только во время PR. Затем вы можете выбрать только PR-события из опции «Позвольте мне выбрать отдельные события».
Вы увидите зеленую галочку в случае успешной настройки веб-перехватчика, как показано ниже.
Если вы не видите зеленую галочку или предупреждающий знак, щелкните ссылку Веб-перехватчики, а затем щелкните последний веб-перехватчик. Вы должны иметь возможность использовать код состояния, чтобы узнать, почему доставка веб-перехватчика не удалась.
Теперь у нас есть вся необходимая конфигурация для многоветвевого конвейера. Следующим шагом является тестирование триггеров рабочего процесса многоветвевого конвейера.
Тестирование многоветвевого пайплайна
В демонстрационных целях я выбрал вариант «Отделение только как отделение PR». С этой опцией обнаруживаются только ветки с PR-запросами.
Чтобы использовать конвейеры с несколькими ответвлениями, вы можете использовать этот репозиторий с образцом Jenkinsfile. https://github.com/devopscube/multibranch-pipeline-demo
Этот репозиторий имеет три ветки. Обновите что-нибудь в README в ветке feature и поднимите PR для разработки. Он отправит веб-перехватчик Дженкинсу, и Дженкинс отправит Дженкинсу детали задания, а PR перейдет в статус проверки, как показано ниже.
Если вы нажмете «Подробности», вы попадете в журнал сборки Jenkins. Вы можете написать пользовательские проверки в файле Jenkins для использования в аудите сборки.
Теперь, если вы выбрали Jenkins, вы найдете конвейер для ветки функций в Jenkins, как показано ниже.
Если сборка завершится неудачно, изменения могут быть зафиксированы в ветке функций, и это будет запускать конвейер функций всякий раз, когда открывается PR.
В Jenkinfile я добавил условие для пропуска фазы развертывания, если ветка не разрабатывается. Вы можете проверить в журнале сборки Jenkins. Кроме того, если вы проверите процесс сборки на информационной панели голубого океана, вы сможете четко увидеть пропущенные этапы развертывания, как показано ниже.
Теперь объедините PR функциональной ветки и переместите новый PR из ветки разработки в основную ветку.
Дженкинс получит веб-хук от Github для нового PR и создаст конвейер разработки, как показано ниже.
Для ветки разработки включен этап развертывания, и если вы проверите процесс сборки Blue Ocean, вы увидите, что все этапы успешно запущены.
Устранение неполадок многоветвевых конвейеров
Я расскажу о некоторых ошибках, с которыми вы можете столкнуться в многоветвевом конвейере, и о том, как их исправить.
проблема обнаружения ветвей
Иногда даже после создания новой ветки в SCM она может не отражаться в пайплайне Jenkins. Вы можете попробовать запустить опцию «Сканировать репозиторий сейчас», чтобы снова просканировать репозиторий. Кроме того, проверьте конфигурацию сканирования репозитория в конвейере.
Вебхуки не запускают конвейеры
Если веб-перехватчик не запускает конвейер, проверьте код состояния доставки веб-перехватчика и ошибки в Github. Также проверьте правильность URL-адреса Jenkins.
Также проверьте журналы Jenkins в разделе «Управление Jenkins» -> «Системные журналы» -> «Все журналы Jenkins». Если Jenkins может получить веб-перехватчик, в журналах должно быть указано, почему задание не было запущено.