Процесс управления релизами для частых выпусков

Процесс управления релизами это набор шагов, который доводит изменение от состояния «влито» до состояния «работает в продакшене и объяснено тем, кого оно касается». Для команды, которая выпускает часто, он сводится к семи шагам: спланировать объём, изолировать изменение, собрать и протестировать, одобрить, выкатить и проверить, сообщить и разобрать итоги. У каждого шага должен быть один названный владелец и один критерий выхода, иначе шаг тихо перестаёт выполняться.

Это руководство рассчитано на команду из 5-50 инженеров, которая выкатывает раз в неделю или каждый день и хочет, чтобы процесс не мешал.

Что такое процесс управления релизами?

Это повторяемый путь, который проходит изменение, чтобы дойти до пользователей: объём, сборка, тесты, одобрение, выкатка, проверка, объявление и взгляд назад. Смысл записать его в том, что каждый релиз идёт одним и тем же путём, и тот, кто в отпуске, новичок или дежурный инженер в два часа ночи могут пройти его, не спрашивая никого, как это делается.

Какие бывают типы управления релизами?

Есть три практических типа: непрерывная выкатка, релизы по расписанию и регулируемое управление изменениями. Они различаются тем, сколько происходит до релиза и сколько автоматизировано. Непрерывная выкатка выпускает каждое влитое изменение, релизы по расписанию собирают изменения в «поезд», а регулируемое управление изменениями добавляет формальное одобрение и журнал для аудита.

Большинство команд смешивают подходы. SaaS-продукт может выкатываться непрерывно, мобильное приложение выходить еженедельным «поездом», а единственный платёжный сервис, который интересует аудиторов, идти по формальной записи об изменении. Выбирайте тип для каждого сервиса, а не для всей компании. Там, где изменения открываются постепенно, выпуск и объявление становятся отдельными событиями, и этот случай разобран в статье release notes для функций за флагом.

Какие обязанности у релиз-менеджера?

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

Перед релизом он подтверждает объём и проверяет, что у каждого рискованного изменения есть путь отката. Во время релиза проходит по чек-листу выкатки, следит за метриками продакшена в первые минуты и откатывает без промедления. После релиза убеждается, что заметки вышли, и записывает, что исправить в процессе.

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

Какие ключевые KPI у управления релизами?

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

Руководство DORA определяет их простыми словами (dora.dev, software delivery metrics):

В более старых материалах говорится о четырёх ключевых метриках, а восстановление называется «time to restore». В нынешнем руководстве используются пять метрик выше.

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

Как коммуникация о релизе вписывается в процесс управления релизами?

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

Самый дешёвый способ держать этот шаг в графике: писать запись, когда изменение вливается, а не когда релиз выходит. В pull request уже есть заголовок, автор, связанная задача и контекст. Черновик, собранный из него, правят, а не пишут по памяти неделю спустя. На этом строится идея автоматизации changelog: получить черновик при слиянии, удержать его до одобрения человеком и опубликовать везде из одного источника. Changeloop работает именно так: составляет записи из влитых pull request с помощью ИИ и удерживает их до одобрения, прежде чем что-либо публикуется.

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

Как сохранить процесс лёгким?

Автоматизируйте каждый критерий выхода, который может проверить машина, а людям оставьте суждения. Зелёный пайплайн, отметка выкатки на дашбордах и черновик записи в changelog на каждый влитый pull request проверяются машиной. Убедителен ли план отката и понятны ли заметки клиенту, решает человек.

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

FAQ

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

Как часто нужно выпускать релизы? Так часто, как позволяют ваши тесты и путь отката, а для многих веб-команд это ежедневно и чаще. Совет DORA: уменьшать размер каждого изменения, потому что мелкие изменения легче проверять и откатывать.

Нужен ли небольшим командам релиз-менеджер? Им нужны обязанности, но не обязательно должность. Меняйте роль между инженерами, дайте дежурному письменный чек-лист и убедитесь, что у каждого из семи шагов есть владелец.

Что должен включать чек-лист релиза? Подтверждённый объём, зелёный пайплайн на выпускаемом коммите, названный путь отката, записанное одобрение, smoke-проверки после выкатки, сравнение метрик с исходным уровнем, опубликованные release notes, уведомлённая поддержка и назначенный разбор. Умещайте на одной странице.

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

По теме на changeloop: Документация для разработчиков, Шаблон релиз-нот