Коли я зв'язала GitLab Merge Requests із Jira у ICanUp, ідея спочатку здавалася простою: створився Merge Request - зміни статус задачі, Merge Request об'єднали - пересунь її далі.
Але дуже швидко стало зрозуміло, що така автоматизація може нашкодити, якщо дозволити їй реагувати на кожну подію без контексту.
Мені була потрібна не автоматизація всього процесу, а тільки двох точок, які GitLab справді може підтвердити сам.
Я не хотіла автоматизувати весь життєвий цикл задачі
Найпростіший варіант - дозволити GitLab рухати задачу від початку роботи до завершення.
Для мене це було неправильним рівнем автоматизації.
GitLab знає, що Merge Request створений або об'єднаний. Але він не знає, чи я вже почала роботу, чи завершила тестування, чи готова задача до production.
Автоматизація повинна приймати рішення тільки там, де в неї є надійний технічний сигнал.
У результаті залишилося тільки два автоматичні переходи
Подія | Початковий статус | Новий статус |
|---|---|---|
Merge Request створений у development | In Progress | Ready for Review |
Merge Request успішно merged у development | Ready for Review | Ready to Test |
Усе інше залишається ручним.
Я сама переводжу задачу в In Progress, коли реально починаю роботу. Після Ready to Test автоматизація також більше не керує задачею.
Manual:To Do | vIn Progress Automatic:In Progress | | Merge Request created vReady for Review | | Merge Request merged vReady to Test Manual after this point:TestingReady to DeployDoneПерша умова - Merge Request має йти саме в development
Створення Merge Request саме по собі ще нічого не означає.
У тому самому репозиторії можуть існувати Merge Requests у development, main або інші гілки.
Автоматичний перехід має відбутися тільки тоді, коли target branch відповідає тому етапу процесу, який ми автоматизуємо.
Event:Merge Request created Required:target branch = development If target branch = main:skipЦе особливо важливо для production Merge Request. Merge у main не повинен повторно змінювати статус Jira-задачі, яка вже пройшла review і тестування.
Друга умова - поточний статус має бути очікуваним
Навіть правильний GitLab event не означає, що Jira-задачу можна пересунути.
Наприклад, Merge Request може бути створений повторно або webhook може прийти тоді, коли задача вже перейшла на наступний етап.
Перед transition я перевіряю не тільки подію, а й поточний статус задачі.
MR created: if current status = In Progress -> Ready for Reviewelse -> skip MR merged: if current status = Ready for Review -> Ready to Testelse -> skipClosed і merged - не одна подія
Ще одна важлива межа - закритий Merge Request не дорівнює успішно об'єднаному.
Merge Request можна закрити через зміну рішення, помилкову гілку або тому, що робота більше не потрібна.
У такому випадку Jira не повинна переходити в Ready to Test.
Merge Request merged-> transition may run Merge Request closed without merge-> no status changeКлюч Jira-задачі потрібно знайти надійно
Щоб GitLab event можна було пов'язати з Jira-задачею, автоматизації потрібен issue key.
У моєму процесі найбільш надійним місцем є назва source branch. Додатково ключ може бути в назві Merge Request, а commit message використовується лише як запасний варіант.
Priority: 1. source branch2. Merge Request title3. commit message as fallback Example branch: feature/PROJECT-123-fix-paginationЯ не прив'язую автоматизацію до одного типу branch prefix.
feature/, fix/, chore/ або інша домовленість можуть змінюватися. Важливим залишається сам ключ задачі.
Повторний webhook не повинен повторювати transition
Webhook не варто сприймати як подію, яка гарантовано приходить один раз.
Повторна доставка, повторний запуск automation rule або інша технічна причина не повинні пересунути задачу ще на один статус.
Одна й та сама подія має залишати систему в тому самому правильному стані.
First event: Ready for Review+ MR merged= Ready to Test Repeated event: Ready to Test+ same MR merged= skipСаме status guard дає тут простий захист. Після першого успішного transition початковий статус уже не збігається, тому повторна подія нічого не робить.
Дві маленькі automation rules виявилися кращими за одну велику
Спочатку може здаватися зручним зробити одну загальну rule, яка знає весь процес задачі.
Але тоді в ній швидко накопичуються умови для opened, merged, closed, target branch, поточного статусу та винятків.
Я віддала перевагу двом правилам з однією відповідальністю кожне.
Rule | Trigger | Єдина дія |
|---|---|---|
Merge Request created | MR створений у development | In Progress -> Ready for Review |
Merge Request merged | MR merged у development | Ready for Review -> Ready to Test |
Rule 1 - Merge Request створений
Trigger:GitLab Merge Request created Conditions:- target branch is development- Jira key can be resolved- current Jira status is In Progress- Merge Request is not closed- Merge Request is not already merged Action:Ready for ReviewRule 2 - Merge Request успішно merged
Trigger:GitLab Merge Request merged Conditions:- target branch is development- Jira key can be resolved- current Jira status is Ready for Review Action:Ready to TestЧому production merge не рухає задачу
Після тестування я можу створити інший Merge Request у main.
Але це вже інший етап доставки.
Якби automation реагувала на будь-який merge, production Merge Request міг би несподівано змінити Jira status вдруге.
Тому target branch є частиною бізнес-правила, а не просто технічною деталлю webhook.
Після Ready to Test рішення знову приймає людина
Автоматизація зупиняється саме там, де GitLab перестає знати достатньо.
Merge Request у development підтверджує, що код увійшов у спільну гілку. Але він не підтверджує, що функціонал протестований або готовий до production.
Тому наступні переходи я залишила ручними.
Ready to Test | | manual vTesting | | manual decision +--> Ready to Deploy | +--> WaitingAudit Log став частиною перевірки
Для таких правил недостатньо побачити, що задача опинилася в правильному статусі.
Потрібно також розуміти, чому automation спрацювала або чому пропустила event.
Тому Audit Log для мене є частиною діагностики, а не другорядним екраном.
- Яка GitLab подія запустила правило.
- Який ключ Jira-задачі було знайдено.
- Який target branch мав Merge Request.
- Який статус Jira був до перевірки.
- Чи було виконано transition.
- Чому event було пропущено, якщо transition не виконувався.
Що я тестую як сценарії
Сценарій | Очікуваний результат |
|---|---|
MR створений у development, status In Progress | Ready for Review |
MR merged у development, status Ready for Review | Ready to Test |
MR закритий без merge | Без змін |
MR створений або merged у main | Без змін |
Повторний merged event | Без повторного transition |
Неочікуваний початковий status | Без примусової зміни |
Зв'язок з моїм CI/CD процесом
Ця автоматизація працює не окремо, а поруч із загальним CI/CD процесом ICanUp.
Я вже окремо описувала як побудований мій Laravel CI/CD pipeline у реальному проєкті.
Тут різниця в тому, що pipeline відповідає за перевірку і доставку коду, а Jira automation - тільки за синхронізацію підтверджених етапів роботи.
Назва branch теж стала частиною контракту
Коли issue key шукається в source branch, назва гілки перестає бути просто зручним підписом.
Вона стає частиною інтеграції між Git і Jira.
Саме тому я намагаюся зберігати ключ задачі в branch name навіть тоді, коли сам Git дозволяє назвати гілку як завгодно.
До речі, важливість акуратної роботи з Git history я вже відчула в іншому реальному кейсі - коли потрібно було перенести вже pushed commit у правильну branch без втрати історії.
Що могло піти не так
- Реагувати на Merge Request у main так само, як на development.
- Вважати closed Merge Request успішно merged.
- Не перевіряти поточний Jira status перед transition.
- Повторно виконувати transition після дубльованого webhook.
- Шукати ключ задачі тільки в commit message.
- Автоматично переводити To Do в In Progress без фактичного початку роботи.
- Автоматично рухати задачу після Ready to Test без результату ручного тестування.
- Ховати всі умови в одну велику automation rule.
Автоматизація має бути консервативною
У цьому кейсі я прийшла до простого принципу: якщо хоча б одна умова не підтверджена, краще нічого не змінювати.
Немає Jira key - пропустити. Неправильний target branch - пропустити. Неочікуваний status - пропустити. Merge Request тільки closed - пропустити.
Для автоматичного transition безпечніше пропустити сумнівну подію, ніж примусово пересунути задачу.
Що я залишила собі на майбутнє
- Автоматизувати тільки ті переходи, які зовнішня система може підтвердити однозначно.
- Перевіряти target branch перед кожним transition.
- Перевіряти поточний Jira status.
- Розрізняти merged і closed Merge Request.
- Будувати правила так, щоб повторна подія була безпечною.
- Використовувати source branch як основне джерело issue key.
- Тримати невеликі automation rules з однією відповідальністю.
- Залишати тестування і production-рішення під ручним контролем.
- Перевіряти Audit Log після зміни automation.
Хороша автоматизація не намагається прийняти всі рішення замість мене. Вона прибирає тільки ті ручні кроки, для яких уже має надійний сигнал.
Висновок
Інтеграція Jira з GitLab стала стабільнішою, коли я перестала дивитися на неї як на спосіб автоматизувати весь процес задачі.
У ICanUp GitLab відповідає тільки за два переходи, які може підтвердити без припущень: Merge Request створений у development і Merge Request успішно merged у development.
Target branch, поточний статус, тип події та повторна доставка webhook перевіряються до зміни задачі. Після Ready to Test керування знову повертається до ручного процесу.
У результаті автоматизація не керує workflow - вона лише синхронізує два факти, які вже відбулися в GitLab.
