Пошаговое руководство по автоматизации рабочего процесса действий 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:

  1. Разработчику назначается тикет JIRA для работы, разработчик создает функциональную ветку от основной ветки, называет ветку номером задачи JIRA, отправляет код, поднимает PR и объединяет PR после утверждения.
  2. Пользователь (разработчик или владелец продукта?) меняет статус заявки JIRA на DEV, автоматизация JIRA запускает рабочий процесс действий GitHub для развертывания артефактов в среде DEV.
  3. Для любых исправлений ошибок разработчик исправляет код, продвигает код, повышает PR и объединяет PR после утверждения.
  4. В случае исправления ошибок статус JIRA можно изменить на другое значение, например IN PROGRESS, а затем снова изменить на DEV, что снова инициирует развертывание последнего артефакта в среде DEV.
  5. После завершения DEV тестирования пользователь меняет статус JIRA на QA, выполняет тот же процесс, что и выше, чтобы перейти к более высоким средам, таким как PROD.
  6. Отчет JIRA может быть получен в любой момент для всех открытых заявок с их полем состояния, отражающим различные этапы их статуса развертывания.
  7. На стороне GitHub все артефакты находятся в основной ветке. Один рабочий процесс обрабатывает как CI, так и CD для всех сред с переменными для среды и номером задачи JIRA, переданными из правила автоматизации JIRA.
  8. Поощряйте настройку правила защиты среды в GitHub, по крайней мере, для сред более высокого уровня, поэтому каждое развертывание должно быть одобрено одним или несколькими назначенными людьми. Это также сделано для того, чтобы избежать жирных пальцев в обновлениях статуса JIRA.

Краткое содержание

В этой статье мы рассмотрели правила автоматизации JIRA, детали конфигурации веб-перехватчиков, среды GitHub и рабочий процесс действий GitHub. Интересно развернуть магию автоматизации между JIRA и GitHub.

Самое интересное заключается в том, что это всего лишь один вариант использования, а между JIRA и GitHub мы можем автоматизировать гораздо больше потоков. Получайте удовольствие от изучения!

Ссылки

Jira Software Automation: Основы | Atlassian

Репозитории — Документы GitHub

Использование сред для развертывания — GitHub Docs