Блог

Швидкість та гнучкість розробки ПЗ відіграють важливу роль. Однак, за одночасної роботи великої команди розробників код розгалуження та злиття може стати безладним. Такі команди необхідно забезпечити процесом одночасного впровадження змін. Ефективна стратегія розгалуження (branching strategy) є пріоритетом у вирішенні цього питання.

Branching strategy є набором правил, яким слідують розробники при написанні, злитті та розгортанні коду при використанні контролю версій. У ситуаціях, коли працюють кілька розробників і вони одночасно додають зміни, стратегія розгалуження структурує репозиторій та дозволяє уникнути плутанини злиття. Конфлікти злиття перешкоджають швидкій доставці коду, заважають створенню та підтримці ефективного процесу DevOps.

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

Стратегія розгалуження дозволяє:

• забезпечити координацію між розробниками та підвищити продуктивність;
• паралельну розробку;
• здійснити заплановані та структуровані релізи;
• внести зміни до ПЗ;
• підтримувати безпомилковий код, а також можливість швидко виправляти проблеми та повертати зміни до робочого середовища без переривання робочого процесу.

Стратегія розгалуження є важливим інструментом. Довільне створення гілок Git різними розробниками може призвести до хаосу. Стратегія розгалуження дозволить перенаправити увагу на процес розробки, а не на управління версіями.

Гілки в Git представлені тегами чи покажчиками. Усі зміни відстежуються у вигляді спрямованого ациклічного графа, кожен вузол якого є набором змін, зроблених одночасно. Гілки Git надають розробникам можливість відхилятися від основної гілки та створювати окремі гілки для ізоляції змін коду. Гілкою за замовчуванням у Git є «main branch»”. Головною перевагою гілки Git є її «незначна вага». Тобто, дані складаються із серії знімків і при кожній фіксації змін Git робить знімок поточного стану файлів і зберігає посилання на нього. Такі гілки є не просто копіями, а й покажчиком на останній коміт.

Основні стратегії розгалуження Git:

• GitFlow – модель, що показує можливість проводити розробку у команді та індивідуально. При цьому життєвий цикл розробки супроводжують лише 2 основні гілки (master та develop). Інші гілки є тимчасовими, за рахунок чого забезпечується постійний порядок у репозиторії;
• GitHub Flow – простіша версія. Вона має тільки гілки master та feature. Поєднання всіх змін у master та часте розгортання дозволило відразу випускати зміни, що відповідає принципам виробництва та безперервної доставки;
• GitLab Flow – пропонує спеціальну гілку production для керування випуском коду у продакшен. Можливе налаштування автоматичного розгортання коду з цієї гілки при кожній зміні в ній. Реліз забезпечується за допомогою злиття з гілки master у production. За допомогою цієї гілки можна отримати дані про випущену версію коду, визначити приблизний час випуску можна за часом створення мерж-комміта;
• Trunk-based development – підхід, що передбачає ведення розробки на основі однієї гілки trunk. Ключовими особливостями підходу є: тимчасове існування гілок (кілька днів), continuous code review (процес перевірки та аналізу коду розробником перед релізом), готовність майстра до релізу у будь-який момент. Такий підхід забезпечує мінімізацію конфліктів при розробці, готовність до релізу без підготовки, швидкий та якісний зворотний зв’язок на PR/MR.

Приклад мердж-конфлікту та його вирішення

Розглянемо приклад виникнення мердж-конфлікту та можливі способи його вирішення з використанням QOps для контролю версій програми Qlik Sense. Для цього візьмемо Qlik Sense додаток і за допомогою QOps створимо репозиторій вихідних кодів та 2 гілки dev1 та dev2 для окремих розробників. Уявимо ситуацію, коли кожен із розробників змінив якийсь загальний елемент (наприклад, колір фону об’єктів з виведенням KPI значень).

Оскільки на рівні вихідних кодів зміни відбулися в тих самих рядках, при виконанні злиття dev1 -> master і dev2 -> master, в останньому виникає мердж-конфлікт. Вирішення мердж-конфлікту вимагає прийняття рішення, який саме з варіантів повинен бути присутнім у зведеному варіанті. Засіб розробки VSCode дозволяє в інтерактивному режимі ухвалити це рішення. Однак, це накладає додаткову відповідальність на IT-фахівця, який виконає це злиття.

Існує ризик отримати від обох розробників частини коду для загального елемента в кінцевому додатку, які можуть бути несумісними. Наприклад, після злиття можна отримати наступний результат, коли для першого об’єкта було обрано рішення Accept Incoming, а для другого – Accept Current.

Зручно проводити злиття вихідних кодів, використовуючи веб-інтерфейс систем контролю версій. Нижче наведено хід виконання Pull Request у GitHub при безконфліктному злитті.

Наявність конфліктних змін призводить до виводу відповідного попередження та додаткової інформації.

Інтерфейс GitHub дозволяє виконати дозвіл мердж-конфліктів у невеликих файлах, при цьому користувачеві потрібно вручну відредагувати вихідний код, позначений конфліктним і підтвердити зміни. У разі неможливості виконання цієї операції через веб-інтерфейс GitHub запросить виконати вирішення конфліктів локально.

Розв’яжемо наявний конфлікт протилежно описаному вище. У результаті отримуємо очікуваний результат із протилежним кольоровим розфарбуванням загальних елементів.

Детальная інформація пhо QOps тут