Как сделать релиз в jira

Добавил пользователь Владимир З.
Обновлено: 15.09.2024

Недавно на стендапе коллега внес рацпредложение: автоматизировать сборку релизов, взяв за основу готовые уже наработки по взаимодействию с Jira, написанные на Python.

Процесс деплоя у нас следующий: когда накапливается достаточное количество задач, прошедших тестирование из них собирается Релиз-кандидат (RC) в каждом проекте, затронутом задачами, затем задачи тестируются в составе RC. После этого RC заливается на стейджинг сервер, где в близком к боевому окружении все еще раз тестируется и проводится полный регресс. И затем, после необходимых деплойных действий свежий релиз заливается в мастер.

До недавнего времени весь процесс сборки проводился кем-либо из разработчиков вручную. Что отнимало час, два и больше времени и было, мне кажется, не очень интересным занятием. Теперь же, когда уже почти все готово, релиз из 20 задач, затрагивающий 5 проектов, собирается меньше минуты. Остается, конечно еще разрешение конфликтов, запуск пропущенных тестов и прочее, но даже с учетом этого, времени разработчиков и тестировщиков, вынужденных ждать, пока кто-то и первых освободится и создаст RC, экономится немало.

В общем, приступил я к задаче, и она оказалась очень интересной и увлекательной. А что еще надо для удовольствия от работы, как не увлекательных проектов?

Я изучил legacy: оказалось оно напрямую использует API Jira, да и написано, как мне показалось, неоптимально. Например, список задач релиза получался следующим образом: с Jira загружались все существующие релизы, а затем каждый из них по названию сравнивался с названием нашего релиза, пока не найдется нужный:

В общем, прямое взаимодействие с API приводит к не очень читабельному коду. Да и велосипед изобретать не хотелось. Первый же поиск на Github привел меня к JIRA Python Library, достаточно простой и мощной библиотеке. Мердж реквесты я изначально планировал создавать с использованием библиотеки GitPython, также найденной на Github. Но дальнейшее изучение вопроса сразу привело к мысли о поисках чего-то связанного не с git, а скорее сразу с Gitlab. В результате, остановился на самом известном решении: Python GitLab.

Начал с получения списка задач в подходящих для релиза статусах. Решил сильно не переделывать прошлое решение, но сделать его эффективнее, сразу запросив у API задачи нужного релиза:

Хотя под капотом там происходит скорее всего то же самое, однако получилось красивее и оптимальнее, но все же не очень читабельно. Далее, из полученных задач, надо собрать ссылки на мердж реквесты. Найденные мердж реквесты решил хранить в namedtuple, они для этого отлично подходят:

Мердж реквесты получал также с помощью API Jira:

После этого решил, где только можно использовать найденные библиотеки. Затем, возможно, отрефакторю эти куски.

Далее надо проверить, вдруг нужные ветки RC уже существуют, если уже были попытки сборки, тогда их надо удалить и создать новые. Это я уже делал с помощью библиотеки Python GitLab:

После этого можно приступить к заполнению таблицы в сборочной задаче Jira. Информация в таблице содержится в следующих колонках: №, Задача, Приоритет, Мердж реквесты из задачи в RC, Статус мердж реквеста (прошли ли тесты в Gitlab, есть или нет конфликты, влит/не влит).

В моем случае, это приводит к ложному статусу конфликта и проверке мердж реквеста вручную. Пока ничего не придумал.

Логика при создании мердж реквестов следующая: если не пройдены тесты, либо есть конфликт, мердж реквесты создаются, но в RC не вливаются, в таблице проставляются соответствующие статусы.

Для проверки выполнения тестов ищем список подходящих pipelines. Gitlab их выдает отсортированными по дате в убывающем порядке, прямо как нам надо. Берем первый — он и будет тем, который нужен:

Затем создаем сами мердж реквесты. Проверяем на наличие открытых, на случай, если это не первая попытка сборки. В случае отсутствия нужного мердж реквеста, создаем такой:

MR.issue.replace('-', '_') — изменение имени задачи, чтобы избавиться от малоинформативных комментариев Gitlaba к задаче в Jira.

Далее смотрим статус полученного мердж реквеста: если нет конфликта, вливаем его в RC. Если конфликт есть, проставляем соответствующие статусы и оставляем для ручной проверки.

Далее по аналогии создаем мердж реквесты из RC в Staging и из Staging в Master для всех проектов. Они будут влиты после проверки всей сборки релиза в RC ветках.

В шаблоне задачи Jira добавили два поля: для преддеплойных и постдеплойных действий. Для всех затронутых задач, алгоритм собирает список таких действий и вносит в сборочную задачу, чтобы ничего не забыть.

Ну и наконец, вывод результата в Jira — создание сборочной задачи:

Дальше мысли следующие: запуск скрипта на Gitlab вебхуком от Jira. Можно, например, сделать вебхук на создание сборочной задачи (завести под нее особый тип задачи), либо создание задачи со словом “Сборка” в названии. А Gitlab по этому хуку будет либо запускать скрипт на bash, начинающий весь процесс, либо поднимать Docker образ с Python и запускать скрипт на нем. Хотя второй вариант уже излишне сложен. Да и нужны технические аккаунты в Jira и Gitlab. В общем, окончательного решения пока нет.

Так же можно после создания веток RC развернуть тестовый стенд на нужных ветках и запустить регресс тесты. Дженкинс с этим справится. Но это тоже пока в планах.

Затевалось это все ради ускорения работы тестировщиков и освобождения разработчиков от рутинной работы. Однако экономический смысл тут тоже вполне конкретный: возьмем среднего разработчика (в вакууме) с гипотетической зарплатой 150000 рублей за 8 часов рабочего времени в день. За два года у нас было порядка 700 релизов — это примерно по релизу в день. Некоторые больше, некоторые меньше, но в среднем, я думаю, минимум час времени разработчика на сборку релиза уходил. То есть, автоматизация данного процесса экономит компании минимум 150000/8 = 18750 рублей в месяц.

Попутно для себя сделал отдельный скрипт, показывающий статистику по предстоящему релизу: сколько задач, какие проекты затронуты и т.п. Так как если у меня нет статуса Developer в каком-либо из проектов в Gitlab — будет отказ в доступе при создании мердж реквестов. Также, удобно заранее узнать о деплойных действиях или отловить задачу, попавшую в данный релиз по ошибке. Рассылка уведомлений о релизе была решена с помощью модулей SMTP и email.

Мне решение этой задачи доставило удовольствие: всегда интересно узнать что-то новое и применить это на практике. Будет приятно, если кому-то этот опыт будет полезен.

разработка программного обеспечения;
сопровождение (поддержка) информационных систем;

Каждая задача принадлежит только одному проекту. Каждый проект имеет имя (например, "Курск Сопровождение") и ключ (например, KURSK). Ключ проекта становится первой частью индексов задач (запросов) этого проекта (например, KURSK-101, KURSK-102 и т. д .).

Адрес и учетные данные для доступа к системе предоставляется исполнителем по контракту.

2. Создание задачи JIRA

Для того, чтобы создать новую задачу в JIRA, необходимо выполнить следующие шаги:

3. Введите резюме задачи и заполните все поля - по крайней мере, обязательные, отмеченные звездочкой.

Если вы хотите получить доступ к полям, которые не отображаются в этом диалоговом окне или вы хотите скрыть существующие поля:

Когда вы создадите задачу, JIRA запомнит выбранные вами поля.

Советы:

3. Создание подзадачи

Задача с подзадачами (разделение родительской задачи на ряд небольших задач), полезна тем, что ее можно назначать и отслеживать отдельно другим пользователям JIRA. Это может обеспечить ускорение работы по этой задаче и позволяет каждому пользователю из команды лучше понять, за какую подзадачу он отвечает при решении задачи.

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

Подзадачи всегда относятся к тому же проекту, что и их родительская задача.

3.1. Для того, чтобы создать подзадачу, необходимо выполнить следующие шаги:

1. Перейдите к задаче, которую вы хотели бы иметь родительской задачей для подзадачи, которую вы собираетесь создать

3.2. Работа с подзадачами

Если задача связана с подзадачами, на экране задач отображается список всех подзадач задачи:

4. Прикрепление файла к задаче JIRA

Прикрепление файла к задаче JIRA ( Attach Files ) позволяет пользователю JIRA по его усмотрению прикреплять определенный файл (ы) к задаче.

Чтобы прикрепить файл к задаче JIRA, выполните следующие шаги:

1. Откройте задачу JIRA, к которой вы хотите прикрепить файл.

5. Необязательно: введите комментарий о файлах, которые вы прикрепляете.

5. Редактирование задачи

Для того, чтобы отредактировать существующую задачу в JIRA, необходимо выполнить следующие шаги:

1. Найдите задачу, которую вы хотите отредактировать.

Кроме того, наведите указатель мыши на поле и щелкните значок карандаша, чтобы отредактировать его в строке.

затем введите нужное имя поля.

JIRA запомнит сделанный вами выбор полей для данного проекта.

Советы:

Данная статья относится к циклу статей, которые помогут вам внедрить JIRA SOFTWARE в организации.

Для настройки проекта нам понадобятся подготовленные и настроенные сущности:
— схема типов задач;
— схема бизнес-процессов;
— схема экранов для типов задач;
— схема конфигурации полей;
— схема приоритетов;
— схема оповещений;
— схема прав доступа.

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

Создание проекта JIRA

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

Настройка проекта JIRA

Теперь нам необходимо настроить проект. Переходим в проект и внизу слева нажимаем на шестерёнку (параметры проекта), под которой скрываются настройки проекта:

Откроется сводная страница по проекту, пример:

Далее будет вестись речь о пунктах меню, которое мы видим слева на картинке выше.

Мы увидим, что применилась новая схема к проекту.

Теперь схема привязана к нашему проекту:

Проект настроен и теперь можно вести работы в рамках проекта.

Удаление ненужных сущностей

После того как к проекту вы привязали свои схемы JIRA отвязала от проекта сущности созданные ей при создании проекта. Чтобы JIRA не забивалась ненужными сущностями, мы можем удалить ненужные сущности. Так как некоторые сущности связаны, то их требуется удалять в определённом порядке.

В статье я расскажу о том, как использовать такой инструмент, как Jira, для управления бэклогом при разработке программного обеспечения. Статья будет полезна не только бизнес-аналитикам, продукт-оунерам, но и скрам-мастерам, проектным менеджерам, в принципе любому человеку, который работает с бэклогом и требованиями на проекте. Для того чтобы этот механизм работал у вас на проекте, необходимо следовать определенным правилам и подходам, о которых я расскажу дальше.

Должен сказать сразу, что эта методика не является эталоном или гарантией того, что ваши проблемы исчезнут. Но я четко знаю и с уверенностью могу сказать, что на момент написания статьи по этой методике было реализовано 4 проекта за последние 3 года, и метод работает! Вы можете модифицировать метод под свои нужды. Если не получается самостоятельно, тогда зовите меня :)

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

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

Основные рекомендации и пререквизиты

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

снижение стоимости на поддержание бэклога и управление им;
стандартизация процессов на проекте;
прозрачность происходящего с продуктом.

Поделитесь принципами работы с бэкклогом со своей командой. Расскажите, как вы будете управлять требованиями:

Какие будут процессы?
Кто/когда и на какие встречи должен приходить?
Что вы ожидаете от команды?
Чего команда должна ожидать от вас?
Когда и в каком виде вы будете поставлять им готовые требования на разработку?

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

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

Что надо использовать в Jira для управления бэклогом

По каждому из пунктов я буду приводить свои примеры и объяснение.

Версии (versions) — представляют временные отметки в проекте. В своей практике я всегда использую названия R.1 / R.Next. Все требования, которые появляются в процессе взаимодействия с клиентом в текущем релизе, должны быть зафиксированы и не теряться, поэтому те требования, которые не входят в текущий релиз, я помещаю в R.Next.

Эпик (epic) — это большой объем работ, который может быть разбит на более мелкие объемы. Я создаю эпик тогда, когда работ больше, чем на 3 дня разработки при условии, что этого эпика еще нет. Но не спешите создавать эпики на каждый случай, через пару месяцев запутаетесь. Тут необходимо хорошо подумать и создать оптимальное количество эпиков. Вам необходимо просмотреть весь функционал наперед, разбить на логические блоки и подумать, что будет эпиком в вашем случае.

Теги (labels) — это ключевые слова, по которым можно легко сгруппировать/находить определенную информацию. Например, в своих проектах, я часто использую теги типа Web, APP, Integration. Чтобы быстро искать нужную информацию по разным запросам от разных участников проекта — QA, Клиента, Dev). Донесите всем, какие теги вы уже создали и зачем, а также расскажите команде, что беспорядочное создание тегов по любому поводу приведет к хаосу.

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

Фильтр (issues and filters) — просто мощный инструмент, который позволяет упростить процесс поиска данных или аналитики данных на ежедневной основе. Рекомендую вам использовать быстрые фильтры на верхней панели самой доски.

Issue workflow — это инструмент, который позволяет настроить последовательность статусов и пути их изменения для определенной сущности. В Jira есть стандартные процессы для разных типов сущностей, но я вам настоятельно рекомендую напрячь мозги и подумать над тем, какой процесс будет у вас. После чего их нужно согласовать внутри команды и с людьми заказчика.

Для пользовательской истории у меня вот такой был пример:

Для задач вот такой процесс:

Мы не пытались усложнить себе жизнь. Основной задачей было выполнить работу и минимизировать бюрократию на проектах.

Задача / подзадача (task /sub task) — используется для более детального разделения пользовательской истории разработчиками и QA. О детализации задач идут целые войны! У каждого свой подход и методика, так же, как и по написанию пользовательских историй. Скажу пока одно: чем опытней разработчик, тем детальней описание задач и больше их количество под конкретной пользовательской историей. Задачи нужны в первую очередь самому разработчику, чтобы через неделю он мог вспомнить, что нужно сделать в определенной пользовательской истории.

Баг (bug) — этот тип сущностей служит для фиксирования проблем/недочетов во время разработки. О том, каким должен быть жизненный путь бага, какие должны быть уровни критичности бага и как управлять багами, мы поговорим в отдельной статье.

Схематическая структура Jira для управления бэклогом

Давайте разберемся во всех этих стрелках и прямоугольниках. Основной концепт этой структуры состоит в том, чтобы визуально разбить бэклог на части при помощи фантомных спринтов. Это дает возможность быстро сегментировать пользовательские истории по разным критериям, а также минимизировать количество переходов между интерфейсами в Jira для получения информации.

Перетаскивание истории из одной секции в другую при помощи drag & drop.
Быстрый поиск информации через поиск самого браузера.
Быстрая фильтрация по нескольким параметрам: Релиз + Эпик + настраиваемый быстрый фильтр (Customer OK, Customer Review и так далее).
Быстрая работа с определенной пользовательской историей после ее нахождения.

Секции и их предназначение

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

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

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

На каждой сессии пленнинг покера, BA/PO выбирает подготовленные истории из этого списка и обсуждает с командой. Истории в этой секции уже должны быть проверены клиентом и получено согласие на их реализацию в таком виде.

Истории отсортированы сверху вниз по бизнес-приоритетам.

Как минимум следующие пункты:

требования четкие и недвусмысленные;
мокап;
тестовые данные, если необходимо.

Эта секция нужна, для чтобы каждый участник проекта видел состояние готового бэклога на разработку.

Истории отсортированы сверху вниз по бизнес-приоритетам.

Пример: велосити проекта составляет 100 сторипоинтов. Есть 3 команды, которые разрабатывают по 20/20/60 сторипоинтов в спринт. Общее количество пользовательских историй в данной секции — 15 на сумму 90 сторипоинтов.

Вашей команде не хватает 10 сторипоинтов для полной загрузки каждой из команд.
Вероятность того, что все эти пользовательские истории пойдут в следующий спринт — 50/50. Там могут быть технические зависимости или фичи с низким приоритетом.
Вам необходимо иметь в данной секции в 1,5 больше сторипоинтов для ваших команд, чтобы они имели возможность выбрать и создать равномерную загрузку каждого из членов команды.

Каждая история разбита на задачи для FE, BE, QA.

Критериями хорошо организованного бэклога являются следующие характеристики: Deep, Invest, Dive. Приоритизация, декомпозиция, определение зависимостей и прочее — достаточно большие темы для обсуждения. Я буду отдельно рассказывать о каждой из них. А пока более детально вы можете почитать тут.

Наполнение будущего спринта должно контролироваться ответственным человеком. Почему я не указал конкретную роль? Потому что в зависимости от проекта эта роль может называться по-разному и человек будет выполнять разные обязанности.

Для поддержания работоспособности такого решения вам необходимо использовать теги, а также рассказать о них своему клиенту (тем, кто будет отвечать за утверждение/подписание) требований. Я предлагаю следующий набор тегов и простенький процесс:

CR (Change request) — используется для того, чтобы помечать те пользовательские истории, которые считаются изменениями на требования. Ставится бизнес-аналитиком вендора.
HLE (High level estimate) — используется для того, чтобы показать, что оценка пользовательской истории является высокоуровневой и там есть определенные допущения. Ставится бизнес-аналитиком вендора.
Customer_Review — используется для указания клиенту, что пользовательская история готова к рассмотрению и обсуждению с клиентом. Ставится бизнес-аналитиком вендора.
Customer_Hold — используется для того, чтобы показать, что конкретная пользовательская история нуждается в доработке командой вендора. Ставится человеком со стороны клиента.
Customer_Approved — используется, чтобы отметить конкретную пользовательскую историю как утвержденную. Ставится человеком со стороны клиента.

Более детально, я рассказываю об этом концепте у себя на канале в этом видео.

Как это выглядит в реальности

Многие из вас могут сказать, что этот подход классный только на бумаге и схемах. Привожу вам пример реальной Jira:

Концепты похожего типа обговариваются на таких конференциях, как Atlassian Summit U.S. 2017 (вот видео) Если вы хотите идти в ногу со временем, вам просто необходимо начать разбираться в том, как это построить и как получить максимальную выгоду для своего проекта.

Почему это нужно

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

Команда разработки — это завод, который выпускает продукт итерациями. Чем хуже будет сырье для вашего завода, тем хуже конечный продукт или выше издержки на само производство продукта. Задумайтесь над тем, чтобы перестать разрабатывать программное обеспечение на аматорском уровне и перейти в высшую лигу с четкими процессами и оптимальными трудозатратами. Для этого не обязательно сразу звать Scrum/Agile coach или какого-то сертифицированного специалиста. Достаточно собраться командой внутри своего проекта и поговорить о проблемах, которые у вас сейчас существуют.

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

На сегодняшний день в России все больше и больше людей предпочитают американскую еду такую как гамбургеры, картошка фри. Так это самое.

Эта статья подготовлена на основе доклада Андрея Гненного на GlobalLogic Kharkiv MS TechTalk. Андрей Гненный — Senior Consultant, лидер Cloud-практики GlobalLogic.

Смартфон Meizu Pro 5, который был представлен в конце прошлого месяца, должен был поступить в продажу с 12 октября. Но эти планы пришлось.

Спустя несколько лет после ухода с российского рынка, компания Motorola, а если быть точнее – то только бренд Motorola, который теперь.

[Fail review — рубрика, в якій ми збираємо історії про робочі провали: що відбулось, як виправляли і які висновки зробили.] Надто.

Читайте также: