Release automation і межа дій

Merge і release — різні рішення

PR до main відповідає на питання «чи безпечно прийняти цю зміну?». Release відповідає на інше питання: «який перевірений набір змін ми оголошуємо новою версією?». Зелений CI не формує реліз автоматично.

Claude Code може підготувати матеріали для release, але момент переходу до tag, publish або deploy має бути явною контрольованою межею.

SemVer як орієнтир, а не автоматичний вирок

Claude може запропонувати рівень версії, але людина має перевірити вплив на користувачів, клієнтів, інтеграції та міграції. Пропозиція моделі не є доказом сумісності.

Контрольований release workflow

1. Проаналізуйте зміни від останнього стабільного tag до HEAD.
2. Згрупуйте merged PR або коміти за типами змін і додайте перевірювані посилання.
3. Підготуйте пропозицію версії, changelog та rollback note.
4. Перевірте повноту й правдивість матеріалів людиною.
5. Після погодження створіть tag і лише потім запускайте publish або release job.
6. Збережіть release artifact та фактичні результати delivery.

Що зафіксувати в QUALITY_GATES.md

• що саме готує Claude Code;
• які перевірки обовʼязкові для release candidate;
• де потрібне людське схвалення;
• які кроки не автоматизуються на цьому рівні;
• як перевіряються changelog, release notes і rollback note;
• хто має право на tag, publish і production deploy.

Claude: summarize merged changes and draft release notes
Human: verify scope, version, compatibility and rollback
Human: approve tag and publish
CI: preserve logs and release artifacts

Rollback note як частина release

Чернетка rollback note не гарантує, що rollback безпечний. Перевірте конфігурацію, залежності, міграції та зовнішні інтеграції до публікації release.