Release Management

Когда релиз становится проблемой

В маленькой команде релиз выглядит элементарно: кто-то решил, что код готов, нажал кнопку, написал в чат «задеплоили». Команда растёт, появляется второй сервис, потом третий, потом десятый — и релизы съедают половину пятницы. Кто-то забыл обновить changelog, кто-то поставил неправильную версию, клиенты спрашивают про актуальную версию API, а ответить некому.

Jez Humble и David Farley в «Continuous Delivery» формулируют принцип: болезненный релиз делается реже, а чем реже релизы — тем они болезненнее. Разорвать петлю можно одним способом — автоматизировать всё, что автоматизируется, и превратить релиз в рутину.

Semantic Versioning как контракт

Semantic Versioning (semver) задаёт формат MAJOR.MINOR.PATCH и закрепляет за каждым сегментом конкретный смысл. MAJOR растёт при ломающих изменениях API. MINOR — при добавлении обратно совместимой функциональности. PATCH — при багфиксах. Потребители библиотеки смотрят на номер версии и сразу понимают, чего ждать: обновление с 2.3.1 до 2.4.0 безопасно, а на 3.0.0 — потребует ревью.

Semver хорошо ложится на библиотеки и публичные API, где потребители сами решают, когда обновляться. Продуктовые команды, деплоящие SaaS-приложение и контролирующие единственный инстанс, чаще берут CalVer (Calendar Versioning, формат вроде 2026.03.21) или хеш коммита. WorkOS опубликовали подробный разбор разных схем версионирования и ситуаций, под которые они подходят.

Автоматизация: от коммита до GitHub Release

Ручное управление версиями разваливается с масштабом: кто-то забыл поднять MAJOR при ломающем изменении, кто-то поднял MINOR вместо PATCH. Инструменты автоматизации привязывают версию к содержимому коммитов.

semantic-release анализирует коммиты в формате Conventional Commits (feat:, fix:, BREAKING CHANGE:), считает следующую версию, генерирует changelog, ставит git tag и выкладывает GitHub Release. Весь процесс идёт в CI без участия человека.

release-please от Google использует тот же подход, но создаёт Release PR с обновлённым changelog и версией. Команда ревьюит PR, мержит — и только тогда происходит релиз. Промежуточный шаг даёт контроль без потери автоматизации.

changesets заточен под монорепозитории. Каждый PR содержит файл-описание изменений, при релизе инструмент собирает все описания, считает версии для каждого пакета и генерирует changelog.

Все три инструмента требуют дисциплины в написании коммитов. Команды, пишущие сообщения «fix stuff» и «wip», получат от автоматизации мусорный changelog и кривые версии.

Continuous Delivery vs Continuous Deployment

Humble и Farley разводят два подхода. Continuous Delivery — каждый коммит в main проходит полный пайплайн и в любой момент готов к деплою в production, но решение о деплое принимает человек. Continuous Deployment убирает человека из цепочки: коммит прошёл тесты — автоматически уехал в production.

Continuous Deployment требует зрелой инфраструктуры: надёжных автоматических тестов, feature flags для управления незавершённым функционалом, мониторинга и автоматического отката.

Release trains — компромисс. Команда копит изменения за фиксированный период (неделю или две) и выпускает релиз по расписанию. Spotify и многие мобильные команды живут на release trains, потому что App Store review process добавляет задержку, которую не автоматизируешь.

Стратегии отката

Зрелые команды думают про откат до того, как он понадобится.

Revert commit. git revert создаёт коммит, отменяющий изменения, и этот коммит проходит стандартный пайплайн. Работает при быстром пайплайне (5–10 минут). У команд на trunk-based development revert почти бесплатный — маленькие коммиты легко откатывать по одному.

Blue-green deployment. Два идентичных окружения (blue и green). Новая версия деплоится на неактивное, тестируется, роутер переключает трафик. Откат — переключение роутера обратно, без передеплоя.

Canary releases. Новая версия получает 1–5% трафика. Метрики в норме — процент растёт. Error rate пополз вверх — трафик возвращается на старую версию.

Database migrations — отдельная категория сложности. Код откатить легко, миграцию базы — часто невозможно без потери данных. Expand-and-contract pattern решает задачу: сначала добавляется новый столбец (expand), код переходит на него, старый столбец удаляется позже (contract). Каждый шаг обратно совместим.

Рекомендации

Стартуйте с Conventional Commits и semantic-release (или release-please, если нужен ручной контроль). Автоматический changelog и версионирование экономят часы каждую неделю и убирают целый класс ошибок.

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