Что такое и как реализовать Issue-Driven CI/CD

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Меня зовут Михаил, я работаю DevOps в небольшой компании, которая имеет два названия — SoftCannery/IntroproVentures.

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

В этой статье я хочу поделиться с тем, как просто и эффективно управлять доставкой функционала на основе задач.

Светлое будущее

Для Developers

Представьте на минутку, что теперь Вам не надо перетаскивать «тикет» из «new» в «in progress» из «in progress» в «some other status» и так далее. Все «таски» красиво разбиты на «под таски», все что надо сделать, это отвести ветку, работать в ней и в итоге создать Pull Request. Вся остальная бюрократия осталась где-то там.

Для QA

Что если Вам теперь не надо выяснять развернут ли тот или иной функционал в «Staging» среде, а может он уже в «QA». И вообще, есть ли, что нового «потестить»? Обсудим на митинге? Теперь, все что надо сделать, это открыть «борду» и посмотреть, какие «тикеты» в статусе «Ready for test in QA env», «Ready for test in Dev/Staging env» and so on...

Для DevOps

Такой вопрос как, какие сервисы с какими версиями и в какую среду надо развернуть, не имеет смысла. Все что надо, это сделать фильтр в «Jira» или другую систему для отслеживания задач, который вернет все задачи с отмеченными названиями сервисов и их версий, которые готовы к развертыванию. На основе этого теперь можно автоматически «тригеррить скрипт» для развертывания новых версий, как только они готовы.

Для Managers

Что бы понять статус проекта — смотрим какие таски «In Progress», какие уже готовы для выпуска или какие по каким то причинам «зависли» на QA или UAT среде и так далее. Все статусы актуальны, все выставлены автоматически (за исключением задач для ручного тестирования).

Все это я называю это Issue-driven CI/CD процесс, который я внедрил в один из моих текущих проектов.

Несколько слов про качество

Для меня есть два основных критерия качества разработки:

1. Поставленная задача выполнена.
2. Задача выполнена и протестирована в запланированное время.

Два простых критерия, однако «дьявол кроется в деталях» таких как:

• грамотная разбивка задачи;
• человеческий ресурс;
• непредвиденные обстоятельства, такие как «бросаем все, срочно надо сделать другое»;
• «правильное/оптимальное» тестирование.

И тут на арену выходит ПРОЦЕСС, да, старый добрый процесс, над которым постоянно надо работать, и за которым постоянно надо следить.

Процесс разработки

В данном примере я буду использовать разработку приложения на микросервисах. Разработка выполняется итеративными подходами, спринт занимает 2 недели. Основной инструментарий — GiHub, Jira, JenkinsX (for CI/CD in Kubernetes) и Slack.

По JenkinsX есть хорошая статья на DOU, но если коротко, то на каждый Pull Request разворачивается Kubernetes pod в отдельном Kubernetes namespace-е c snapshot версией, и если все удачно развернулось, то CI pipeline «зеленый» и мы можем добавить изменения в мастер.

При обновлении мастер ветки тригеррится новый pipeline, который добавляет собранный артефакт в nexus, на основе которого добавляется новый container image в container registry, и он же helm-ом разворачивается на Staging среде.
Так же при каждом изменении мастер ветки автоматически создается «tag», название которого есть номер новой версии.

«JenkinsX» использует helm, который позволяет развертывать сервисы на разных средах (не только Staging). Под каждую среду существует отдельный GitHub репозиторий, который содержит в себе helm проект, который в свою очередь содержит в себе yaml файл со списком сервисов c соответствующими версиями. При любом коммите в такой проект, автоматически тригеррится pipeline для развертывания, который также может содержать дополнительные stages, в нашем случае это функциональные автоматические тесты (если это QA среда).

Для описания процесса ниже приведен Jira tasks workflow:

Реализация Issue-Driven CI/CD

Идея заключается в автоматическом процессинге Jira тикета в соответствующий статус. Я условно разбиваю этот подход на две части:

• Continuous Integration
• Процессинг новой версии через среды

Как отобразить CI в нашем Jira workflow

Для этого был создан простой Webhook, который реагирует на «Branch or tag creation», «pull request» и «merge». Второе — мы договорились с программистами, чтобы при создании новой ветки, они в ее имя добавляли идентификатор Jira тикета. В итоге, как только отводится новая ветка наш тикет переводился в статус «In Progress»

Как только, создается PR, тикет переводится в статус «In Review». Как только изменения добавляются в master ветку наш тикет переходит в статус «In Staging»

Можно справедливо заметить, реализация этого функционала уже реализована с помощью уже существующих плагинов, например Smart commits. Однако нас интересует не только CI но и процессинг тикета дальше через все среды до Production.
Поэтому очень важен следующий момент — при переводе тикета в «In Staging» автоматически добавляется комментарий с названием сервиса и его версии.
Этот комментарий мы будем использовать для последующего процессинга.

Процессинг новой версии через все среды до Production

Webhook был доработан следующей функциональностью — как только тригеррится развертывание новой версии, в этот момент «парсится» yaml файл со списком сервисов и версий нашего JenkinsX проекта (тот что для развертывания в другой среде) и соответственно выполняется jql запрос для поиска соответствующих тикетов по комментариям, в которых указаны название сервисов и версий. В случае если версия из файла равно или больше версии из комментария, то выполняется автоматическая попытка перевода тикета в соответствующий статус с комментарием.

Параллельно происходит нотификация в Slack.

Slack-нотификации

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

Вот как выглядят нотификации в нашем проекте:

Как видно из примера выше, у нас есть «warning» сообщения о том, что тикет не был в правильном статусе, но новая версия все же попала в QA среду. Соответственно, в зависимости от правил Jira workflow тикет может и не перевестись в новый статус.

Итоги

В результате мы имеем автоматический перевод тикетов в соответствии его действительного статуса. Если процесс нарушен, то мы имеем об этом нотификацию. CI/CD процесс прозрачен и визуализирован на основе Jira Issue Workflow. Jira Board передает реальный статус текущей разработки. Есть автоматическая генерация, того, что доставляется.

Также этот подход дополнительный драйвер на удобную разбивку задач на подзадачи, что хорошо сказывается на планировании и сроках. Функционал webhook-a можно расширять и дополнять. Не вижу проблем если такой подход надо реализовать не на Jira + GitHub + Slack, главное, что бы другие инструменты предоставляли необходимый API.