Розгалуження Git

Джерело фото: https://goo.su/r8KGnt

Якою має бути основна гілка: master, develop чи щось ще? Погляньмо на стратегію розгалуження Git, з якою ви можете бути ще не знайомі.

На які питання має відповідати стратегія розгалуження?

1. На якій гілці треба створювати feature гілку?
2. Після завершення коду в якій гілці потрібно створювати MR (Merge Request) / PR (Pull Request) для перевірки і тестування коду?
3. З якою гілкою зливати цю feature гілку після завершення тестування та аналізу?

Важливі речі, які має вирішувати стратегія розгалуження

1. Гілка, на якій ви створюєте функціональну гілку, має бути стабільною у продакшні.
2. Не можна зливати код з помилками або непротестований код із продакшн гілкою (гілка, звідки ви робите деплой).
3. У процесі злиття вашого коду з продакшн-гілкою ви маєте зіткнутися з мінімальною кількістю конфліктів злиття.

Мета стратегії розгалуження полягає в тому, щоб підвищити стабільність коду та продуктивність розробників та уникнути зайвих конфліктів. Я не зачіпатиму всіх типів стратегій розгалуження, але я назву кращу, яка застосовується найчастіше. У ній використовуються гілки master, develop і feature.

master

1. Ми називаємо її продакшн гілкою. У ній є добре протестований стабільний код.
2. З цієї гілки мав відбутися попередній реліз, і наступний також має бути з неї.
3. У нас можуть бути пайплайни для релізу з цієї гілки (тобто щоразу, коли відбувається чергове злиття в цю гілку, автоматично запускається пайплайн, який робить збір та деплой ПЗ на наші робочі сервери).
4. Вона повинна приймати злиття тільки з гілкою develop.

develop

1. Гілка на нижньому по відношенню до master рівні.
2. Розробник, який починає працювати над якоюсь функцією, створює нову гілку з цієї гілки.
3. Після завершення розробки/тестування/аналізу коду розробник створює MR/PR на ту саму гілку, оскільки саме з цієї гілки ми збиратимемо наступний реліз.
4. Для того, щоб зарелізувати стан проекту в цій гілці, ми робимо мерж у гілку master.

feature

1. Гілка, що створюється з develop для роботи над запланованою на наступний випуск функцією.
2. Зазвичай у цій гілці працює один розробник.

Поділ на ці три типи гілки допомагає уникати непотрібних конфліктів та підвищує продуктивність команди.

Тестування QA

Однак, ми пропустили одну річ: тестування QA. На якій гілці його робити? Інакше кажучи, яку гілку слід розгорнути середовищу QA? Найпростіший підхід: мати середовище QA на гілці розробки (тобто сервери QA будуть розгорнуті зі збіркою, що випускається з гілки develop). А після завершення тестування та контролю якості створюється MR/PR у гілку master.

Стратегія з 2 гілками:

Плюси

1. Кожна зміна може бути протестована до релізу через єдину збірку/розгортання (тобто, тестування окремих функцій може бути проведено за один раз для всіх функцій).
2. Після тестування функцій ця гілка найбільше підходить для регресійного тестування, оскільки для наступного випуску у ній вже заплановані зміни.

Мінуси

1. Якщо у змінах в одній із feature гілок є баг, то тестування та QA буде заблоковано та забере багато часу у команди.

Варіанти рішення

Перше рішення

Зачекати, поки автор feature-гілки виправить проблему. Злити її з гілкою develop, знову розгорнути в середовищі QA і відновити тестування. Але це недоцільний варіант, оскільки ми не знаємо, скільки часу знадобиться на виправлення того чи іншого бага. Крім цього:

1. Це втрата часу для команди QA.
2. Блокування релізів, якщо реліз може пройти навіть без цієї функції.
3. Топтання на місці у гілці develop, якщо QA виявляє баги у кількох функціях.

Друге рішення

Скасувати зміни цієї функції та продовжити тестування. Такий підхід ефективніший з точки зору продуктивності команди, проте для автора feature-гілки він може бути болючим. Скасування змін призведе до створення нового коміту, що спричинить скасування всіх змін від цих розробників у цій гілці. А якщо вони спробують після виправлення багів злити її назад, Git буде використовувати для злиття з develop тільки нові коміти виправлень, оскільки старіші коміти вже знаходяться в історії комітів develop. Щоб вирішити цю проблему, розробнику потрібно скасувати коміт скасування.

Третє рішення

Третім і найпростішим рішенням буде примусово запушити master у develop, заново злити решту гілок feature і заново запустити QA. Для продуктивності команди я порекомендував би другий шлях.

Найкращий підхід

Всю цю проблему можна вирішити наступним чином: створити ще одне гілку QA для тестування. В ідеалі QA має оновлюватися разом із develop. Таким чином з'явиться додатковий крок, і весь функціональний цикл виглядатиме так:

1. Починаєте нову гілку з develop.
2. Після розробки та тестування створюєте PR/MR на QA для аналізу коду.
3. Після аналізу коду зливаєте її з гілкою QA.
4. QA проводить тестування функції і після тесту ви створюєте MR/PR на develop.
5. Проводьте другий раунд аналізу (для спокою) та зливаєте вашу гілку безпосередньо в develop, оскільки вона вже проаналізована та протестована.
6. Як тільки develop готова до релізу (тобто всі feature гілки злиті), QA запускає складання для проведення регресійного тестування. Цей білд можна запустити у створеному середовищі QA.

Стратегія з 3 гілками:

Переваги цього підходу

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

1. Ви можете проводити тестування функцій на гілці QA, регресійне тестування на стабільній гілці develop після злиття всіх функцій, які заплановані в поточному випуску.
2. Гілка develop завжди буде стабільна, а будь-який розробник зможе пустити від неї свою гілку feature у будь-який час.
3. Ви не засмічуватимете історію комітів у гілці develop.
4. Якщо у QA з'являться проблеми з будь-якою гілкою feature, ви зможете їх вирішити і провести без скасування змін, якщо ця функція є незалежною від інших.
5. Патч (hotfix): у разі будь-якої проблеми з продуктом почніть гілку з master, виправте проблему і зарелізуйте.

Сподіваємось Вам допомогла ця стаття :)

Джерело: https://goo.su/DprgoQU
Переклад українською мовою: Аліна Берестень
Адміністратор: Дмитро Берестень