Чекліст релізу й деплою для Jira

Що таке чекліст релізу?

Чекліст релізу перетворює продакшен-запуск на кроки, які можна позначити на робочому елементі: готовність до релізу, збірка й артефакти, погодження змін, сам деплой, smoke-тести й моніторинг, rollback і закриття. Заголовки лишаються стабільними; позначки, SHA й нотатки змінюються з кожним деплоєм.

Команди відвантажують по-різному. Команди continuous delivery викреслять рядки про вікно змін. Тижневі реліз-поїзди залишать їх. Вважайте список стартовим runbook і збережіть свою версію, щоб п’ятничний продакшен-реліз не залежав від пам’яті.

Чому команди тримають чекліст релізу на завданні

Runbook на вікі-сторінці чи в Slack-треді легко пропустити, коли деплой стартує. Чекліст на робочому елементі тримає SHA, вікно, smoke-тести й шлях rollback там, де вже живе зміна, — реліз-менеджери, on-call і розробники бачать ту саму роботу, що лишилася.

Той самий каркас працює, чи відвантажуєте ви безперервно, чи у вікні змін: відкриваєте завдання, бачите, що лишилося, позначаєте по ходу й записуєте, що сталося, якщо щось пішло не так. Низькоризикові перемикання флагу можуть прибрати рядки про погодження, комунікації й rollback; за високого ризику вони лишаються.

Коли застосовувати

Використовуйте чекліст релізу, коли зміна йде в продакшен — на story, яку відвантажують, або на окремому change-завданні, якщо в деплою свої власник, дати й workflow. Автозастосовуйте його, коли статус стає Ready to release або Deploying, щоб runbook з’явився до вікна. Скорочуйте рядки для низькоризикових безперервних деплоїв; залишайте погодження, комунікації й rollback, коли зміна видима користувачам або її важко відкотити.

Реліз vs. QA-тестування vs. Definition of Done

Цей чекліст QA-тестування — тестовий прохід до відкриття вікна. Definition of Done — спільна планка виходу на story: review, тести й готовність до релізу, які кожен елемент винен наприкінці. Чекліст релізу — runbook запуску на зміні, яка реально йде. Тримайте їх окремими списками, щоб тестовий прохід, планка відвантаження й продакшен-вікно лишалися різними. Acceptance criteria досі описують поведінку, яку ви виводите в прод.

Реліз і деплой — приклад для старту

Щоб зібрати перший чекліст релізу, почніть з прикладу нижче. Скопіюйте список і вставте його в поле Checklist for Jira на change- або релізному робочому елементі. Ідеально: зберегти як шаблон і автозастосовувати, коли робота переходить у Ready to release — так кожен деплой отримує стійкий каркас і ті самі заголовки. Приберіть рядки, які команда пропускає; додайте ті, що потрібні процесу.

Реліз і деплой

Готовність до релізу
Change, feature flag і ключі тікетів перелічено на цьому робочому елементі
Стейкхолдери й on-call знають вікно або причину, чому воно безперервне
Ризик, blast radius і на що дивитися записані на робочому елементі
Збірка й артефакти
Артефакт білду або SHA коміту записано
Верифікація в pre-prod або staging зроблена або письмово знята
Секрети, сертифікати й доступ для деплою на місці
Безпека й погодження змін
Security-рев’ю або нотатки про загрози пов’язані, якщо зміна чутлива
Погодження, які вимагає ваша політика, записані на робочому елементі
Деплой
Кроки продакшен-деплою пройшли в задокументованому порядку
Міграції або зміни конфігу завершилися без невідповідених помилок
Feature flags відповідають цільовій аудиторії
Smoke-тести й моніторинг
Smoke-тести на продакшен-шляху пройшли
Частота помилок, латентність і бізнес-KPI виглядають нормально для вікна
Дашборди моніторингу й алерти зміненого сервісу відкрито
Rollback, комунікації й закриття
Шлях rollback або вимкнення достатньо перевірений, щоб ним користуватися
Support, success або статус-сторінка оновлені, коли користувачі бачать зміну
Інцидент або follow-up робочий елемент пов’язано, якщо реліз завдав шкоди
Нотатки після релізу й завдання, що лишилися, зафіксовано на цьому завданні

Цей каркас належить зміні, яку відвантажують. У Checklist for Jira ви додаєте або позначаєте пункти на панелі завдання, зберігаєте заголовки як проєктний або глобальний шаблон і автозастосовуєте, коли статус стає Ready to release — або вручну через Add → Add from template, коли потрібно.

Поставте це на робочий елемент із Checklist for Jira

Шаблони, автоматизація, обмеження в процесі та агент Rovo — безкоштовно для команд до 10 користувачів.

Спробувати безкоштовно на Atlassian Marketplace

Збережіть стартер, автоматизуйте runbook

Checklist for Jira додає панель чекліста на вигляді завдання. Вставте приклад вище на change- або релізний робочий елемент, підженіть рядки під процес і збережіть форму як проєктний або глобальний шаблон у Checklist settings.
Позначте шаблон як Protected, якщо runbook має бути зафіксований, поки люди позначають пункти, — щоб кроки не стискалися тихо від деплою до деплою.
Використовуйте автоматизацію шаблону, щоб вішати каркас релізу, коли статус стає Ready to release або Deploying. Ці автоматизації вбудовані в Checklist for Jira і працюють без кредитів Jira Automation.
Якщо команді потрібен жорсткий гейт, додайте валідатор завершення на shipped-статус, обмежений цим шаблоном. Post function може скинути список, якщо ви відкочуєтесь і пробуєте знову. Jira Automation може застосувати, завершити або скинути той самий список, коли умова багатша за один статус.
Поєднуйте з чекліст QA-тестування до вікна і Definition of Done на story — див. посібник з автоматизації.

Чекліст релізу на change у Jira, з іще відкритими пунктами комунікацій і rollback.

Поєднуйте з рештою delivery-набору

Тримайте чекліст QA-тестування на завданні, поки прохід не стане зеленим. Вішайте Definition of Done на story, щоб планка відвантаження була видима з першого дня. Використовуйте Definition of Ready на refinement, якщо якість intake допомагає команді. Повний набір — у хаб шаблонів.

Часті запитання

Чи має реліз жити на окремому завданні Jira?

Якщо деплой — справжній проєкт зі своїм власником, датами й workflow, окреме завдання або підзавдання доречне. Якщо runbook — список перевірок на вже наявній зміні, тримайте чекліст на цьому робочому елементі.

Чи потрібен кожній команді той самий чекліст релізу?

Ні. Почніть з одного шаблону й скоротіть. Команди continuous delivery часто прибирають рядки про вікно змін і погодження. Регульований тижневий поїзд залишить погодження, комунікації й rollback. Збережіть другий шаблон, коли два продукти тримають різні runbook.

Чи можуть глобальні шаблони обслуговувати кожен проєкт?

Так. Адміністратори Jira зберігають глобальні шаблони; адміністратори проєкту — проєктні. Protected глобальні runbook — сильний default, коли кілька команд мають відвантажувати однаково.

Як скинути список після rollback?

Додайте post function або Jira Automation reset-all на перехід назад із shipped, обмежений так, щоб очищався лише список релізу. Посібник з автоматизації розбирає reset і валідатори завершення.