Release automation и граница действий

1. Релиз — отдельная граница после merge

Когда первый PR зелёный, второй зелёный, а CI радостно моргает зелёным, возникает очень человеческое желание сказать: «Всё, релиз готов». И вот тут обычно начинается маленькая инженерная магия, которая легко переходит в маленький инженерный хаос. Merge и release случаются после одних галочек, но отвечают на разные вопросы. PR → main: можно ли безопасно принять изменение в основную ветку. main → release: какой набор принятых изменений мы считаем новой версией и как это зафиксировать, чтобы через неделю не гадать по логам и памяти команды.

Для Commerce OS это выглядит очень жизненно. Представьте, что в main попали три изменения: убрали дубли в /api/orders, починили порядок заявок на возврат в support inbox, обновили README с командами локального запуска. Все прошли review. Но пока нет версии, changelog, тега и записи «что вошло» — нет и ответа менеджеру: «А что мы сегодня выкатываем?»

Полезно держать в голове такую короткую таблицу:

Отсюда и главный сдвиг мышления: release automation — это не «сделать кнопку публикации покрасивее». Это сделать момент упаковки релиза проверяемым и понятным. Иначе у вас будет зелёный код, но туманный релиз — а это примерно как идеально собранный чемодан без билета и адреса аэропорта.

2. Артефакт и действие: главная граница релиза

На этой теме чаще всего спотыкаются новички, потому что снаружи кажется, будто «подготовить релиз» — это одна операция. На самом деле внутри неё живут две очень разные сущности. Первая — артефакт, то есть текст, файл, сводка, заметка или предложение. Вторая — действие, то есть операция, которая уже меняет состояние репозитория, реестра пакетов, страницы релиза или другой системы.

Это различие критично для работы с Claude. Claude прекрасно готовит артефакты. Он умеет быстро собрать changelog из merged PR, предложить новую версию, написать черновик release notes и даже собрать rollback note на основе истории коммитов. Но как только речь переходит к созданию тега, публикации артефакта или запуску release job, мы выходим из зоны «подготовить текст» в зону «совершить действие с последствиями».

Для Commerce OS это можно разложить так:

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

Именно поэтому в release automation всегда полезно задавать себе вопрос: это сейчас описание релиза или уже операция над релизом? Пока вы отвечаете «описание», Claude — отличный помощник. Как только честный ответ — «операция», обязан появиться человек, который читает, проверяет и осознанно нажимает кнопку.

3. Версия, changelog и тег без мистики

Слова semver, tag, release notes легко звучат как что-то для взрослых разработчиков с бородой и клавиатурой за ползарплаты. На самом деле базовая механика очень простая. Версия — это способ назвать конкретное состояние продукта. Changelog — это человеческое объяснение, что в этой версии изменилось. Тег — это метка в Git, которая указывает ровно на тот коммит, который вы считаете релизом.

Если совсем по-простому, версия 1.6.0 — это не магическое число, а договорённость команды. Обычно используется такая логика:

Claude здесь может очень помочь: он умеет собрать список изменений и предложить, почему версия похожа на patch, minor или major. Но финальное решение всё равно остаётся человеческим, потому что именно человек понимает, действительно ли это изменение ломает ожидания внешних пользователей или других сервисов.

С changelog всё ещё проще. Это обычный markdown-файл, который объясняет, что попало в релиз. Например:

## [1.6.0] - 2026-05-24

### Исправлено
- Убраны дубли в `/api/orders`.
- Исправлен порядок refund-заявок в support inbox.

### Изменено
- Обновлены инструкции локального запуска Commerce OS.

А тег — это просто метка на конкретном коммите:

git tag v1.6.0          # помечаем конкретный коммит как релиз
git push origin v1.6.0  # отправляем тег в удалённый репозиторий

Здесь важен не сам синтаксис — Git тут прямолинеен, спасибо ему за редкую вежливость. Важна дисциплина: тег ставится после проверки changelog, версии и состава релиза, а не «давайте быстро проставим, потом разберёмся». Tag — это действие, а не заметка на полях.

Ещё одна полезная тонкость: CHANGELOG.md и release notes похожи, но это не одно и то же. CHANGELOG.md живёт в репозитории. Release notes — это текст для страницы релиза, письма, карточки в хостинге. Claude может собрать один из другого, но проверяются оба одинаково: без выдуманных пунктов и «красиво звучащих» улучшений, которых в PR не было.

4. Claude готовит релиз, не выпускает его

Когда команда впервые включает Claude в release workflow, очень хочется попросить: «Подготовь релиз». Формулировка красивая, но опасная — границы в этом нет. Полезнее маленькие задачи: собрать изменения между тегами, сгруппировать PR, предложить версию, подготовить rollback note.

В Commerce OS это удобно строить на уже изученном Workflow Kit. Skill release-notes не «умеет выпускать релиз», а умеет ровно одно: превращать историю merged PR в черновик заметок. Claude тут не автопилот, а быстрый редактор и аналитик.

Вот пример нормального запроса для такой задачи:

Собери черновик релизных заметок по изменениям между тегами v1.5.0 и HEAD.
Сгруппируй пункты на:
- пользовательские изменения
- исправления
- внутренние улучшения

Для каждого пункта укажи источник: PR или commit.
Не придумывай изменений, которых нет в истории.
Отдельно предложи новую версию и коротко объясни выбор.

Почему такой запрос хорош? У него ограниченный вход, ограниченный выход и понятный критерий проверки. Claude не создаёт теги, ничего не публикует и не делает вид, будто знает историю проекта лучше, чем реально видит в Git. По истории Commerce OS он вернёт что-то вроде такого:

### Предлагаемая версия
`1.6.0`

Причина: есть исправления ошибок и одно небольшое функциональное улучшение без ломающих изменений API.

### Исправления
- PR #418: устранены дубли в `/api/orders`
- PR #421: исправлен порядок refund-заявок в support inbox

### Внутренние улучшения
- PR #423: обновлены инструкции локального запуска в README

Если такой черновик нужен регулярно, вопрос смещается с текста на форму инструмента: где хватает skill, а где команда вот-вот построит лишнюю автоматику.

Это уже полезный черновик. Но именно черновик. Здесь часто совершают очень понятную ошибку: раз текст выглядит убедительно, значит, его можно не читать. Нет, читать всё равно надо. Claude может сгруппировать не туда или пропустить скрытый breaking change: PR выглядит как «внутреннее улучшение», а внутри тихо меняет формат внешнего ответа — и minor превращается в major. У модели нет чувства корпоративной боли, у команды — есть.

Поэтому хорошая формула звучит так: Claude собирает, человек утверждает. И чем опаснее шаг, тем жёстче граница.

5. Release-логика в QUALITY_GATES.md

До этого момента QUALITY_GATES.md уже описывал движение change через PR и merge, рядом могли появиться docs-правила. Теперь у него появляется ещё одна секция — не PR → main, а main → release candidate. Тот же артефакт, две разные decision boundary.

## main -> release candidate

### Claude готовит
- черновик `CHANGELOG.md`
- сводку merged PR с прошлого тега
- предложение новой версии
- черновик rollback note

### Требует согласования человека
- создание тега релиза
- публикация release artifact
- запуск publish job

### Не автоматизируем на этом уровне
- production deploy
- destructive DB migration
- force-push и удаление тегов

Так в одном месте живут и правила merge, и правила release candidate — без ощущения, что команда живёт по трём разным шаблонам. Обратите внимание на полезную мелочь: здесь нет попытки сказать «AI review теперь сам решает, выпускать ли релиз».

Полезно также помнить связь с docs-as-code, она тут прямая. Changelog и release notes — документация, значит, их проверяют против реальной истории PR, коммитов и тегов. Написано «добавлен новый фильтр для операторов поддержки», а такого PR в релизе нет — это не «косметическая неточность». Это ошибка релизного артефакта, чинить её надо как неправильный README.

Небольшая схема процесса выглядит так:

flowchart TD
    A[Слитые PR в main] --> B[Claude собирает черновик changelog и версии]
    B --> C[Человек проверяет текст и состав релиза]
    C --> D[Создаётся тег релиза]
    D --> E[Публикуется release artifact]

На схеме намеренно нет production deploy. Не потому что его не существует, а потому что сегодня мы сознательно держим границу раньше: учимся упаковывать релиз и не путать текстовую подготовку с опасными действиями.

6. Rollback note экономит нервы

С release automation почти всегда происходит одна и та же история. Пока всё хорошо, rollback note кажется скучным бюрократическим приложением. Но в тот день, когда релиз пошёл не туда, он становится самым любимым документом всей команды. Поэтому лучше подружиться с ним заранее — пока никто не бегает по созвонам с «на какой тег мы откатывались?»

Огромным он быть не должен. Для Commerce OS на уровне developer literacy хватает минимального шаблона:

## Заметка про откат
- last known good tag: `v1.5.2`
- revert path: откатить merge-коммит PR #421 и вернуть релиз на `v1.5.2`
- data impact: миграций нет
- owner: release engineer on duty

Почему это важно именно в сегодняшней теме? Потому что rollback note — идеальный пример релизного артефакта. Claude поможет его собрать. Но ответственность за корректность текста без человека он не возьмёт: только человек знает, не было ли в одном из merged PR скрытого изменения конфигурации, зависимостей или внешнего сервиса, неочевидного из summary.

Здесь часто возникает соблазн махнуть рукой: «Ну у нас же небольшой сервис, если что — откатим». На деле именно небольшие команды страдают без rollback note сильнее всего: знания живут в головах, а не в документах. Один отпуск, одно увольнение, один тяжёлый спринт — и знание «как вернуть прошлую стабильную версию» испаряется быстрее кофе на митапе DevOps.

Если сформулировать совсем коротко, хороший rollback note делает релиз не только выпускаемым, но и обратимым. А обратимость — одна из самых недооценённых форм инженерного спокойствия.

7. Цельный сценарий релиза в Commerce OS

Полезно в конце собрать всё в один живой сценарий, чтобы тема не распалась на термины. Обычная неделя Commerce OS: те же три PR в main, проверки прошли, готовим релиз. Claude через skill вроде release-notes собирает изменения между последним тегом и HEAD, предлагает версию 1.6.0, пишет черновик changelog и rollback note. Дальше важное: человек сверяет пункты с merged PR, ловит скрытый breaking change, проверяет, что changelog не врёт, — и только тогда соглашается с версией. Потом тег, потом публикация. Не наоборот.

И вот в этот момент release automation становится нормальной инженерной системой. У команды есть ответ на четыре вопроса. Что вошло в релиз? Почему версия именно такая? Где зафиксировано состояние? Как откатиться, если всё пошло не по плану? Пока ответить быстро и спокойно нельзя — релиз ещё не собран, даже если CI давно зелёный.

И когда в QUALITY_GATES.md есть раздел про release candidate, а рядом живут честный changelog, аккуратный tag и короткий rollback note, релиз перестаёт быть лотереей. Он становится ещё одной управляемой инженерной границей — почти без магии, зато с куда меньшим количеством внезапных приключений.