«Однажды в далёкой, далёкой галактике...»
Иван работал QA-инженером в довольно большой команде. Команда занималась сразу несколькими проектами, связанными между собой. Команда была дружная, у каждого участника в глазах был тот самый огонёк, заставлявший всё время изобретать и не дававший сидеть на месте. Ивану это нравилось. Каждый релиз был для команды новым вызовом, и Андрей, лидер команды, часто повторял: «Я вообще не понимаю, что у нас происходит».
На очередном планировании спринта (а команда работала по Scrum), Андрей увидел в бэклоге несколько задач, которые висели там уже несколько месяцев.
— А разве мы не зарелизили уже эти фичи?
— Зарелизили, они уже в проме.
— А когда?
— Примерно пару релизов назад, как-раз месяц прошёл.
— Хорошо, но что-то я не помню. Точно в проме уже? Тогда закрыть надо... А эти задачи мы готовы выкатить? Напоминаю, по плану у нас выкатка ПСИ назначена через неделю, будет окно у безопасников.
— Так-то готовы, но я сейчас там как раз заканчиваю ещё одну фичу, можно будет всё сразу выкатить. — ответил один из разработчиков.
— Здорово! А сколько времени тебе надо, чтобы закончить?
— Пара часов буквально. До завтра сделаю. В крайнем случае — завтра.
— Ну хорошо, давайте пока не собирать релиз, подождем. — принял решение Андрей.
На следующий день на дейли Иван задал вопрос:
— Как там дела с релизом? Пора бы уже его выкатывать на стенд ИФТ и начинать тестирование. Компонентов много, интеграционное тестирование будет сложным.
— Ну, я почти закончил ту фичу. Правда, там появилась зависимость от другого модуля, и нужны изменения в pipeline со стороны DevOps. И да, я уже не могу разделить фичи. Там работы буквально на пару часов осталось, закончу сегодня, как и обещал.
Примерно такой же разговор состоялся и на третий день, и тогда выяснилось, что фича была готова накануне поздно вечером, а для правки pipleline нужен ещё день. На четвёртый день релиз собрали. Началось тестирование в том его виде, когда пытаются успеть всё сделать в последний момент. На следующий день было ПСИ.
Что такое «Отсечка релиза»?
Отсечка релиза, или Code (Feature) Freeze, это этап в разработке ПО, который предназначен для устранения риска возникновения ошибок в последний момент перед релизом. В условиях нехватки времени на разработку, строгих дедлайнов и множества задач (особенно с учётом метрики LeadTime в Сбере) этим этапом часто пренебрегают.
Отсечка релиза позволяет проверить RC (Release Candidate — кандидат в релизы) на отсутствие дефектов и, в случае нахождения таких дефектов, исправить их.
Применение отсечки вовсе не означает, что разработка останавливается: она продолжается на отдельных ветках, а найденные дефекты исправляют в самом релизе, либо в последующих.
Отсечка также не означает, что тестирование останавливается с момента выкатки текущего релиза до отсечки следующего. В это время идёт разработка новых тестов, локальное тестирование фич, подготовка окружения.
С другой стороны, отсечка позволяет разграничить процессы разработки и тестирования именно в рамках текущего релиза.
«Новая надежда»
— Предлагаю ввести отсечку релизов, — Иван был настойчив. С другой стороны, ретро на закрытии спринта для того и нужно, чтобы обсуждать проблемы и предлагать идеи.
— Что-то сомневаюсь, что это будет полезно. А что, если я немного не успею закончить фичу? Откладывать до следующего релиза? Звучит как-то не очень.
— Мне тоже не нравится. Получается, что я должен заранее «подписываться» под конкретные даты…
— А я не знаю… У нас вроде и так всё неплохо было.
— Коллеги, мне тоже было бы удобнее планировать релизы, — Андрей рассуждал вслух. — У нас есть проблемы с окнами для выкатки на ПСИ, без этого мы не можем двигаться дальше. С другой стороны, мы можем забронировать время на несколько недель вперёд, но тогда мы должны понимать, что релизы должны выходить регулярно.
— Ещё один плюс отсечки — история, можно будет не вспоминать, когда и что было выпущено. Релизов у нас много, зависимостей — ещё больше. История релизов поможет решить проблему, — несмотря на тяжёлый спринт, Иван хорошо подумал над преимуществами и недостатками своего предложения.
— А как насчёт багов? Когда их править? Вот найдём на тестировании проблемы, и что, не исправлять их теперь?
— Баги можно и нужно исправлять. Особенно критические. Баги с низким приоритетом можно исправить в следующем релизе, запланировав их в спринт.
— Ладно, давайте попробуем. Один-два релизных цикла, а там посмотрим. Не понравится — откажемся, — решил Андрей.
Что даёт отсечка?
У разработчиков появляется уверенность, что в релиз уходит именно ожидаемая конфигурация продукта. Это особенно важно, если в разработке находятся зависимые компоненты или разработка ведётся совместно.
Для QA-инженеров появляется гарантированное окно в жизненном цикле продукта, когда можно проводить регрессионное тестирование, не опасаясь, что очередное изменение заставит переделывать всю работу с нуля. Также упрощается локализация дефектов и отслеживание их истории (например, для поиска источника проблемы и понимания масштаба влияния).
У руководителей появляется понимание, какие фичи готовы к релизу, а какие нет; насколько команда близка к достижению поставленных целей. Также отслеживаются зависимости связанных компонент и продуктов.
Как выбрать дату отсечки?
Отсечка — не формальный инструмент. Для начала нужно определиться с желаемой частотой релизов. Их регулярность добавляет предсказуемости результату и прозрачности процессу разработки.
Также нужно выделить время на тестирование. Оно определяется как среднее время по историческим данным. Например, в проекте Provisioning команды CMDB Inventory периодичность релизов — две недели, а время, необходимое на полное тестирование (регресс и новая функциональность) — 4 дня. Таким образом, к концу шестого рабочего дня в релиз вносят все готовые фичи и исправления. Задачи со статусом «ну вот ещё пару часиков, и всё» в релиз не попадают.
Как сделать процесс отсечки более прозрачным?
Есть несколько рекомендаций на этот счёт:
Выпускать версии регулярно.
Для наполнения релизов в день отсечки лучше назначить отдельную встречу, посвящённую только этому вопросу. На встрече должны быть разработчики (ответственные за функциональность в релизе), QA-инженеры (подготовка к тестированию релиза), аналитики (убедиться, что все зависимости готовы) и владельцы продукта (понимание объёма выполненных работ и степени готовности продукта в целом).
Составить «Карту релизов» — таблицу, в которой будет название и номер релиза, дата отсечки, состав релиза (Bugfix и название задач на разработку новых фич из Jira), планируемая дата выхода на ПСИ, а также контакты людей, ответственных за разработку. Карта релиза должна содержать информацию о прошлых, текущем и будущих релизах. Это поможет в планировании, наглядно показывая все зависимости.
Заполнять карту релизов по мере выполнения задач, что сэкономит время на встречах. Этим могут заниматься QA-инженеры и/или релиз-менеджеры, как самые заинтересованные в этом процессе люди.
Не пытаться добавить функциональность в релиз в последний момент.
Регулярно пересматривать окно тестирования как в большую, так и в меньшую сторону для будущих отсечек, но не делать этого слишком часто. Статистические отклонения ещё не повод к резким изменениям процесса.
Как можно разделить релизы?
Для разделения релизов хорошо подходят ветки. Каждый релиз можно собирать в своей отдельной ветке, куда после отсечки также будут вливаться исправления найденных дефектов.
В случае использования компилированных сборок есть вариант использования стендов. Так как все сборки хранятся в Nexus, а для тестирования используется (в идеале) стенд ИФТ, то новые сборки нельзя раскатывать на ИФТ до тех пор, пока не закончится тестирование текущего релиза.
«Империя наносит ответный удар»
— Привет всем, давайте начнём фиксацию релиза. В прошлый раз мы запланировали пять релизов. Мы готовы их выкатывать? Давайте посмотрим… — Иван открыл первый релиз из списка в карте релизов. — Так, все фичи сделаны, переведены в QA… Отлично! Есть что-то, что осталось здесь сделать?
— Надо подтянуть секреты на стенды и подготовить pipeline-ы для выкатки.
— Вадим, когда можно ожидать новые пайпы?
Вадим, DevOps-инженер команды, задумался:
— У меня сейчас очень большая нагрузка. До вечера не успею.
— Хорошо, тогда отложим релиз этого модуля на следующий раз.
Через две недели (стандартный принятый релизный цикл) на митинге, посвящённом фиксации релизов, обсуждение повторилось:
— Вадим, как там про пайпы для модуля?
— Нет, ещё не приступал. Занят другими модулями.
— Хорошо. А что у нас с зависимостями от этого модуля?
— У нас ещё два модуля зависят от новой функциональности. Они готовы к выкатке, но работать не будут.
— А мы можем подождать ещё?
Что может пойти не так?
Могут быть задержки в проверке релизов на ПСИ, могут быть зависимости от других команд, могут быть проблемы с выкаткой сборок на стенды. При этом сроки релизов, конечно, будут сдвигаться в бо̒льшую сторону. В таких ситуациях стоит проанализировать проблему и найти способы её недопущения в будущем.
«Пробуждение силы»
Команда решила проводить короткие встречи, посвящённые релизам, каждую неделю при двухнедельном релизном цикле. Это позволило понимать, где в данный момент находится команда.
— Коллеги, у нас накопилось много релизов, завязанных на конкретную функциональность. Pipeline-ы готовы, давайте выкатим эту фичу на неделю раньше, протестируем её отдельно. Это позволит лучше протестировать остальные модули, а заодно уменьшит нагрузку на QA и DevOps. Что скажете?
— Да, звучит вполне разумно. Давайте так и сделаем.
— У нас уже запланированы релизы на два месяца вперёд. У кого-нибудь есть вопросы, чем предстоит заниматься ближайшее время? Может быть, есть идеи, что можно выкатить ещё?
— Так-то всё понятно, только вот сейчас заканчиваю функциональность, которую мы не планировали выкатывать ближайшее время. Давайте запланируем релиз?
— Да, конечно. У него будут какие-нибудь зависимости? Вадим знает, что от него ожидается? Стоит добавить задачу на DevOps?