image

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

После трансформации весь описанный выше функционал перешёл в одну группу — «Управление релизами». Коммуникации, работу с командой тестирования, отчётность и встречи — всё стала вести наша команда.

Большая часть коммуникаций проходила в почте. Сбор, фиксацию состава релиза и отчётность — всё приходилось делать вручную. Процесс подготовки к релизу занимал до пяти рабочих дней. Релиз-менеджер каждый день из confluence сохранял pdf-файл со списком задач и сравнивал состав релиза на предмет добавленных и исключённых задач. После включения задачи в релиз тест-менеджеры самостоятельно вносили её на страницу «Актуализация регрессов» на confluence согласно цветовой легенде и определяли, какие задачи требуют изменения в тестовой модели, а какие ещё не брали в работу. Было много ручных активностей релиз-менеджеров и тест-менеджеров, и это заставило нас подумать над частичной автоматизацией процесса ведения релизов.

Дальше я расскажу в деталях, как всё было «до» и как стало «после».

В Управлении в отделе нагрузочного тестирования уже был частично разработан QAD — quality assurance dashboard. В QAD много функционала, справочников, составов дистрибутивов, наборов тестов, компонентов, профилей. Этот инструмент позволяет при помощи фильтров Jira формировать и отслеживать изменения в составе списка задач и частично — отчётность. От нас достаточно сформировать задачу на сопровождение QAD с полным описанием потребностей и желаемым результатом, а потом на промежуточных встречах мы обсуждаем нюансы, при необходимости вносим корректировки, договариваемся о сроках исполнения и ждём реализации.

Совместными усилиями отделов нагрузочного и интеграционного тестирования мы постепенно наполняем QAD теми функциями, без которых сейчас не обходится ни один релиз.

1. Формирование состава релиза

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

Раньше список был только в confluence. После реализации доработки в QAD релиз-менеджер вносит в него те же фильтры и делает синхронизацию. Задачи попадают в QAD в блок «На согласовании», далее после ручной проверки статусов и наличия актуальных протоколов акцептует задачи. Если всё заполнено верно, то задача согласовывается и попадает уже в блок «Согласованные». Для удобства в использовании и одновременном просмотре всех необходимых полей страницу состава релиза можно настроить, вывести все необходимые поля: команда, стрим, автор, даты, коммиты и версии и т. д.

image

2. Happy path включённых в релиз задач

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

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

Что мы сделали? Первое — это обратились ко всем владельцам проектов Jira с просьбой добавить поле Happy path. На встрече по фиксации скоупа релиза всем командам озвучивается информация о том, что Happy path должен быть пройден в определённый срок согласно контрольным точкам графика релизов, в противном случае задача будет исключена из состава релиза. На странице состава релиза в QAD вывели поле Happy path и добавили возможность формирования таблицы со списком задач. Далее на авторов и исполнителей уже адресно направляем письмо о необходимости прохождения и заполнения Happy path.

image

3. Информация о релизе

Помимо сухого списка задач, нам захотелось визуализировать релизы. В релиз подаются задачи, их количество может быть разным (80, 100, 150…) от разных команд. На странице «Инфо» в QAD формируются диаграммы и графики. Для дальнейшего анализа считаем, сколько задач в релизе подано в разрезе по командам, а также сколько задач включается в релиз после его фиксации.

image

image

4. Фиксация изменений в составе дистрибутивов

До фриза состав релиза может быть изменён: можно включить или исключить задачу. Для контроля состава добавили возможность фиксировать пересборки дистрибутива с указанием дат, систем, времени и состава изменений.

image

5. Актуализации регрессов

Почти каждая задача несёт в себе изменения того или иного функционала. Нужна коммуникация в нашей большой команде, чтобы найти того, кто внесёт изменения в кейсы. Тест-менеджеры назначают ответственных и следят за исполнением. В начале статьи уже упоминалось о том, что ранее тест-менеджеры отдельно по каждому релизу вели страницу на confluence. Мы приняли решение перенести эту активность в QAD. В текущей реализации страница наполнена множеством фильтров по проектам, статусам, исполнителям, командам, системам. Добавлены различные варианты поиска и формирования отчётности для удобства самих тест-менеджеров и руководителей.

image

6. Ведение ошибок с регрессионной среды и позже — пострелизных ошибок с промышленной среды

Немаловажная активность релиз-менеджера — контроль и ведение ошибок во время релиза и после его выхода. С помощью фильтра Jira вносим в QAD все ошибки, найденные во время тестирования релиза. Здесь можно оставить комментарии, посмотреть статусы и сформировать отчёт. В разрезе по релизам все ошибки и комментарии сохраняются, при необходимости можно вернуться в прошлые релизы и посмотреть историю.

image
image

А так как ведение релиза не заканчивается его выходом на промышленную среду, то позже была добавлена таблица по сопровождению инцидентов пострелизного периода. Её заполнение — ручное: номер инцидента, описание, систему и дату обнаружения берём из периодического отчёта от коллег из мониторинга, далее уже проводим анализ и формируем заключение.

image

7. Страница «Версии микросервисов»

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

image

8. Ограничения при внедрении релиза

При установке релиза на промышленную среду есть ряд ограничений. Ранее вся коммуникация была в почте и собиралась с исполнителей вручную. После того как эта страница была добавлена в QAD, отпала необходимость сбора в почте: наше сопровождение в блоке «Ограничения» сохраняет свои отметки о статусе приёмки дистрибутивов и времени работ, формируются списки сотрудников, которые будут выходить на установку. Нам остаётся только нажать на кнопку «Сформировать письмо» и отправить всю собранную информацию на необходимых получателей.

image

На сегодняшний момент в QAD находятся не только «Общебанковские релизы», но и «Релизы платёжных систем», внеплановые патчи и команда «Онлайн-заявки». Автоматизация рассылок, сбора писем, формирование отчётности — всё это сократило наши ресурсы на проведение и сопровождение всего релиза в целом. И на этом мы не останавливаемся!

Комментарии (2)


  1. IVNSTN
    19.03.2024 19:28

    Happy path

    Это просто яркое название или где-то действительно прописан некий путь, который должна пройти задача? Контроль прохождения и заполнение поля делегированы автоматике или, так сказать, под честное слово того, кто это поле заполнит руками?

    QAD

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


  1. Yulia_Vonsul Автор
    19.03.2024 19:28
    +1

    За прохождение HappyPath ответственность лежит на исполнителе по задаче, со своей стороны мы отслеживаем факт и проставление меток.

    Qad- это внутренняя разработка, интегрированная с jira.