Пошаговое руководство по автоматизации рабочего процесса действий GitHub из JIRA с помощью отправки репозитория.
Автоматизация позволяет нам сосредоточиться на важной работе, избавляя от необходимости выполнять ручные повторяющиеся задачи, позволяя нам автоматизировать наши процессы и рабочие процессы. JIRA предлагает простой, но мощный конструктор правил, и мы можем настроить правила автоматизации для обработки даже самых сложных сценариев.
В этой статье мы собираемся изучить, как автоматизировать обновления статуса задачи JIRA, чтобы инициировать рабочий процесс действий GitHub для развертывания артефактов микросервиса Spring Boot в ECS Fargate для различных сред. Наша цель:
- Пользователь обновляет статус задачи JIRA на
DEV
; артефакт развертывается в средеDEV
с помощью рабочего процесса действий GitHub. - Пользователь обновляет статус задачи JIRA на
QA
; затем артефакты соответственно развертываются в средеQA
. - Развертывание Prod происходит таким же образом.
Давайте определим правило автоматизации в JIRA для обработки этого рабочего процесса, рассматриваемого в нашем случае использования. Смотрите скриншот ниже:
Несколько моментов, чтобы упомянуть:
- Поскольку вариант использования сосредоточен вокруг поля
status
в задаче JIRA, мы начинаем наше правило сWhen: Issue transitioned
. - Мы используем
if/else
условия для уточнения деталей правила. - Если статус равен
DEV
, мы инициируем вызов веб-перехватчика, чтобы отправить событие отправки репозитория в рабочий процесс действий GitHub для развертывания артефактов в средеDEV
. - Если статус равен
QA
, мы инициируем вызов веб-перехватчика, чтобы отправить событие отправки репозитория в рабочий процесс действий GitHub для развертывания артефактов в средеQA
. - Если статус равен
PROD
, мы инициируем вызов веб-перехватчика, чтобы отправить событие отправки репозитория в рабочий процесс действий GitHub для развертывания артефактов в средеPROD
.
Предположение: правило может быть создано только пользователем с правами администратора для конкретного проекта в JIRA.
Конфигурация вебхука
Давайте подробнее рассмотрим, как мы определяем вебхук в нашем правиле. Смотрите скриншот ниже. Этот веб-хук, по сути, представляет собой вызов REST API к API отправки репозитория GitHub. Отправка репозитория — это просто HTTP-запрос к нашему репозиторию с просьбой к GitHub запустить какое-либо действие или веб-перехватчик.
Используя эту функцию, мы можем либо вручную инициировать действия GitHub с помощью отправки репозитория, либо настроить приложение, такое как JIRA, для запуска действия путем отправки веб-запроса.
Несколько вещей, на которые стоит обратить внимание:
- Для этой конечной точки требуется доступ для записи в репозиторий.
Authorization
раздела заголовка должно иметь значениеBearer <github token>
. Без этого вызов невозможен. - Раздел пользовательских данных. Конструкция выглядит следующим образом:
event_type
: мы можем определить тип нашего события какevent-triggered-by-jira
. Позже в рабочем процессе GitHub Actions мы фильтруем по этому конкретному типу события для обработки. Если тип события, определенный здесь, совпадает с типом события в рабочем процессе действий GitHub, мы можем назвать его как угодно, если это имеет смысл.- Параметр
client_payload
доступен для любой дополнительной информации, которая может понадобиться нашему рабочему процессу. Этот параметр представляет собой полезные данные JSON, которые будут переданы при отправке события веб-перехватчика. В нашем случае мы определяем два параметра: jira-issue
: это номер задачи JIRA в виде интеллектуального значения JIRA{{issue.key}}
. Мы можем использовать этот номер задачи JIRA в комментарии фиксации в рабочем процессе действий GitHub.env
: это среда, которую мы хотим передать рабочему процессу действий GitHub, чтобы артефакты можно было развертывать в этой конкретной среде, определенной здесь.
Вот и все, что касается определения правила. Теперь давайте перейдем к GitHub.
Среды GitHub
Среды GitHub используются для описания общей цели развертывания, такой как DEV
, QA
или PROD
. Мы можем настроить среды с секретами, специфичными для среды. Секреты репозитория действуют как секреты по умолчанию/резервные копии. Секреты среды перезаписывают секреты репозитория.
Мы также можем настроить правила защиты среды для более высоких сред, таких как PROD
. Мы можем настроить до шести рецензентов, чтобы убедиться, что развертывание на PROD
действительно запланировано и одобрено.
Рабочий процесс действий GitHub
Именно здесь происходит фактическое развертывание артефактов. Полный workflow.yml
смотрите на скриншоте ниже. В этот yml-файл добавлены комментарии, поясняющие назначение каждого действия. Обратите внимание на отсутствие жестко запрограммированных сред или других переменных, чтобы мы могли использовать тот же рабочий процесс yml для развертывания в других средах, основанных на триггере JIRA status
.
Несколько вещей, на которые следует обратить внимание:
- Строки 34–36: это триггер, который мы определили через веб-перехватчик в правиле автоматизации JIRA. Убедитесь, что значение типа события совпадает с тем, которое определено в пользовательских данных веб-перехватчика. В противном случае этот рабочий процесс не будет запущен.
- Строка 58: Здесь GitHub Environments творит чудеса. Мы передаем значение
env
, определенное в пользовательских данных вебхука, в форме${{ github.event.client_payload.env }}
. Это говорит GitHub извлечь секреты этой конкретной среды и проверить ее правила защиты, чтобы развернуть артефакты в этой конкретной среде. - Строки 188–193: были добавлены для фиксации комментария после вышеуказанных шагов, поэтому пользователи, которые смотрят это репо, получают уведомление по электронной почте о том, что конкретная проблема JIRA была развернута в среде, выбранной в JIRA.
Конечный результат
Вот обзор упрощенного процесса развертывания, вызванного проблемами JIRA:
- Разработчику назначается тикет JIRA для работы, разработчик создает функциональную ветку от основной ветки, называет ветку номером задачи JIRA, отправляет код, поднимает PR и объединяет PR после утверждения.
- Пользователь (разработчик или владелец продукта?) меняет статус заявки JIRA на
DEV
, автоматизация JIRA запускает рабочий процесс действий GitHub для развертывания артефактов в средеDEV
. - Для любых исправлений ошибок разработчик исправляет код, продвигает код, повышает PR и объединяет PR после утверждения.
- В случае исправления ошибок статус JIRA можно изменить на другое значение, например
IN PROGRESS
, а затем снова изменить наDEV
, что снова инициирует развертывание последнего артефакта в средеDEV
. - После завершения
DEV
тестирования пользователь меняет статус JIRA наQA
, выполняет тот же процесс, что и выше, чтобы перейти к более высоким средам, таким какPROD
. - Отчет JIRA может быть получен в любой момент для всех открытых заявок с их полем состояния, отражающим различные этапы их статуса развертывания.
- На стороне GitHub все артефакты находятся в основной ветке. Один рабочий процесс обрабатывает как CI, так и CD для всех сред с переменными для среды и номером задачи JIRA, переданными из правила автоматизации JIRA.
- Поощряйте настройку правила защиты среды в GitHub, по крайней мере, для сред более высокого уровня, поэтому каждое развертывание должно быть одобрено одним или несколькими назначенными людьми. Это также сделано для того, чтобы избежать жирных пальцев в обновлениях статуса JIRA.
Краткое содержание
В этой статье мы рассмотрели правила автоматизации JIRA, детали конфигурации веб-перехватчиков, среды GitHub и рабочий процесс действий GitHub. Интересно развернуть магию автоматизации между JIRA и GitHub.
Самое интересное заключается в том, что это всего лишь один вариант использования, а между JIRA и GitHub мы можем автоматизировать гораздо больше потоков. Получайте удовольствие от изучения!
Ссылки
Jira Software Automation: Основы | Atlassian