До начала 2020 года наша команда принимала участие в релизах в качестве группы тестировщиков во главе с координатором. Процесс был полностью ручным, длительным и требовал достаточно много времени. Координатор занимался формированием команд на регрессы, отслеживанием активностей, ведением дашборда и прочими организационными мероприятиями внутри команды тестирования. При этом основной функционал — формирование состава релиза, коммуникация между командой тестирования и разработчиками, ведение встреч и прочих мероприятий по релизам — был на смежном управлении: всё это делали релиз-менеджеры, и именно они были головой релиза.
После трансформации весь описанный выше функционал перешёл в одну группу — «Управление релизами». Коммуникации, работу с командой тестирования, отчётность и встречи — всё стала вести наша команда.
Большая часть коммуникаций проходила в почте. Сбор, фиксацию состава релиза и отчётность — всё приходилось делать вручную. Процесс подготовки к релизу занимал до пяти рабочих дней. Релиз-менеджер каждый день из confluence сохранял pdf-файл со списком задач и сравнивал состав релиза на предмет добавленных и исключённых задач. После включения задачи в релиз тест-менеджеры самостоятельно вносили её на страницу «Актуализация регрессов» на confluence согласно цветовой легенде и определяли, какие задачи требуют изменения в тестовой модели, а какие ещё не брали в работу. Было много ручных активностей релиз-менеджеров и тест-менеджеров, и это заставило нас подумать над частичной автоматизацией процесса ведения релизов.
Дальше я расскажу в деталях, как всё было «до» и как стало «после».
В Управлении в отделе нагрузочного тестирования уже был частично разработан QAD — quality assurance dashboard. В QAD много функционала, справочников, составов дистрибутивов, наборов тестов, компонентов, профилей. Этот инструмент позволяет при помощи фильтров Jira формировать и отслеживать изменения в составе списка задач и частично — отчётность. От нас достаточно сформировать задачу на сопровождение QAD с полным описанием потребностей и желаемым результатом, а потом на промежуточных встречах мы обсуждаем нюансы, при необходимости вносим корректировки, договариваемся о сроках исполнения и ждём реализации.
Совместными усилиями отделов нагрузочного и интеграционного тестирования мы постепенно наполняем QAD теми функциями, без которых сейчас не обходится ни один релиз.
1. Формирование состава релиза
Помним, что на общей встрече с командами формируется список задач, которые входят в скоуп релиза. Релиз-менеджер подготавливает фильтры в Jira для каждой команды, акцептует поданные задачи, проверяет на правильность заполнения полей, наличие протоколов и завершение тестирования.
Раньше список был только в confluence. После реализации доработки в QAD релиз-менеджер вносит в него те же фильтры и делает синхронизацию. Задачи попадают в QAD в блок «На согласовании», далее после ручной проверки статусов и наличия актуальных протоколов акцептует задачи. Если всё заполнено верно, то задача согласовывается и попадает уже в блок «Согласованные». Для удобства в использовании и одновременном просмотре всех необходимых полей страницу состава релиза можно настроить, вывести все необходимые поля: команда, стрим, автор, даты, коммиты и версии и т. д.
2. Happy path включённых в релиз задач
После включения задачи в релиз необходимо, чтобы команда, в которой разрабатывалась задача, прошла Happy path на регрессионной среде.
Раньше формировалась страница на том же confluence, на ней команды проставляли соответствующие статусы по задачам: Happy path — пройден, не пройден, не требуется. Не всегда и не все делали это оперативно, да и во многих проектах в Jira это поле просто отсутствовало для заполнения, поэтому кто-то вносил информацию в комментариях, а кто-то ставил метки. Единого понимания не было. Релиз-менеджерам часто приходилось возвращаться на эту страницу и точечно отслеживать каждую задачу. Сколько на это уходило времени, мы не считали, остаётся только догадываться, что немало.
Что мы сделали? Первое — это обратились ко всем владельцам проектов Jira с просьбой добавить поле Happy path. На встрече по фиксации скоупа релиза всем командам озвучивается информация о том, что Happy path должен быть пройден в определённый срок согласно контрольным точкам графика релизов, в противном случае задача будет исключена из состава релиза. На странице состава релиза в QAD вывели поле Happy path и добавили возможность формирования таблицы со списком задач. Далее на авторов и исполнителей уже адресно направляем письмо о необходимости прохождения и заполнения Happy path.
3. Информация о релизе
Помимо сухого списка задач, нам захотелось визуализировать релизы. В релиз подаются задачи, их количество может быть разным (80, 100, 150…) от разных команд. На странице «Инфо» в QAD формируются диаграммы и графики. Для дальнейшего анализа считаем, сколько задач в релизе подано в разрезе по командам, а также сколько задач включается в релиз после его фиксации.
4. Фиксация изменений в составе дистрибутивов
До фриза состав релиза может быть изменён: можно включить или исключить задачу. Для контроля состава добавили возможность фиксировать пересборки дистрибутива с указанием дат, систем, времени и состава изменений.
5. Актуализации регрессов
Почти каждая задача несёт в себе изменения того или иного функционала. Нужна коммуникация в нашей большой команде, чтобы найти того, кто внесёт изменения в кейсы. Тест-менеджеры назначают ответственных и следят за исполнением. В начале статьи уже упоминалось о том, что ранее тест-менеджеры отдельно по каждому релизу вели страницу на confluence. Мы приняли решение перенести эту активность в QAD. В текущей реализации страница наполнена множеством фильтров по проектам, статусам, исполнителям, командам, системам. Добавлены различные варианты поиска и формирования отчётности для удобства самих тест-менеджеров и руководителей.
6. Ведение ошибок с регрессионной среды и позже — пострелизных ошибок с промышленной среды
Немаловажная активность релиз-менеджера — контроль и ведение ошибок во время релиза и после его выхода. С помощью фильтра Jira вносим в QAD все ошибки, найденные во время тестирования релиза. Здесь можно оставить комментарии, посмотреть статусы и сформировать отчёт. В разрезе по релизам все ошибки и комментарии сохраняются, при необходимости можно вернуться в прошлые релизы и посмотреть историю.
А так как ведение релиза не заканчивается его выходом на промышленную среду, то позже была добавлена таблица по сопровождению инцидентов пострелизного периода. Её заполнение — ручное: номер инцидента, описание, систему и дату обнаружения берём из периодического отчёта от коллег из мониторинга, далее уже проводим анализ и формируем заключение.
7. Страница «Версии микросервисов»
Позволяет сравнить версии и коммиты, установленные на среду тестирования с промышленной. Ранее был отдельный инструмент — rancher-dashboard, который не мог отобразить всей информации, а показывал состав только в рамках одного микросервиса, и разницу нужно было определить самим. После реализации очередной доработки в QAD мы видим полный состав и список микросервисов, изменения по которым вошли в состав релиза. Если версии в задаче не совпадают с теми, что установлены на среде, то это видно по красной заливке.
8. Ограничения при внедрении релиза
При установке релиза на промышленную среду есть ряд ограничений. Ранее вся коммуникация была в почте и собиралась с исполнителей вручную. После того как эта страница была добавлена в QAD, отпала необходимость сбора в почте: наше сопровождение в блоке «Ограничения» сохраняет свои отметки о статусе приёмки дистрибутивов и времени работ, формируются списки сотрудников, которые будут выходить на установку. Нам остаётся только нажать на кнопку «Сформировать письмо» и отправить всю собранную информацию на необходимых получателей.
На сегодняшний момент в QAD находятся не только «Общебанковские релизы», но и «Релизы платёжных систем», внеплановые патчи и команда «Онлайн-заявки». Автоматизация рассылок, сбора писем, формирование отчётности — всё это сократило наши ресурсы на проведение и сопровождение всего релиза в целом. И на этом мы не останавливаемся!