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 и версионирование экономят часы каждую неделю и убирают целый класс ошибок.

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