Trunk-based development: щоденні мерджі в main простими словами для продактів

Trunk-based development — це спосіб роботи, за якого кожен розробник щонайменше раз на день мерджить маленькі зміни в одну спільну гілку — стовбур, зазвичай main, — а все недописане ховає за feature flag. Фічевих гілок, які живуть тижнями, тут немає: гілка живе кілька годин, від сили день. Сенс у тому, щоб уся команда постійно працювала на одному коді, а кожна зміна була достатньо маленькою, щоб її можна було швидко переглянути, протестувати й викласти.

Єдине правило, яке все тримає

Уся модель тримається на одному правилі: мерджити в стовбур щонайменше раз на робочий день. «Стовбур» (trunk) — це давня назва головної гілки дерева, і в Git вона означає головну гілку — ту, що називається main (або master у старіших репозиторіях). Усе інше відгалужується від неї й швидко в неї повертається.

Протилежність — це «довгоживуча фічева гілка»: гілка, яка живе тиждень або довше, поки хтось наодинці будує фічу, а потім одним махом вливає величезну купу змін. Trunk-based development існує, щоб ця купа була якнайменшою. Замість одного великого мерджу наприкінці тижня ви отримуєте багато крихітних мерджів щодня.

Як виглядає робочий день

Розробник бере маленький, самодостатній шматок роботи, а не цілу фічу. Він відгалужується від main, робить два-три коміти, за кілька годин відкриває pull request, і того ж дня його переглядають і мерджать. Якщо фіча готова лише наполовину, готові частини все одно мерджать — але за feature flag, тобто перемикачем, який вмикає чи вимикає цю частину продукту без нового деплою.

Для дрібної правки в один рядок багато команд узагалі не заводять гілку: комітять одразу в main, бо таку маленьку зміну легко перевірити на місці й так само легко відкотити, якщо вона щось зламала.

Ритм, який варто запам'ятати: маленька гілка, швидке рев'ю, мердж, деплой — і так по колу.

Навіщо команди так працюють

1. Майже зникають конфлікти при мерджі. Конфлікт виникає, коли двоє людей змінили ті самі рядки. Малі й часті мерджі означають, що зміни майже не перетинаються, а якщо й перетинаються — конфлікт на кілька рядків, а не на кілька сотень.
2. Рев'ю стає швидким і чесним. Переглянути зміну на 30 рядків легко; переглянути зміну на 3 000 рядків — це переглянути по діагоналі й щось пропустити. Малі зміни перевіряють по-справжньому.
3. Стовбур завжди майже готовий до релізу. Оскільки main щодня отримує протестовану роботу, команда може викласти його майже будь-якої миті. Немає «тижня стабілізації», коли все завмирає.
4. Стає можливою безперервна доставка. Коли кожен мердж маленький і протестований, викласти його автоматично — це маленький крок, а не стрибок у невідоме. Команди, які деплоять багато разів на день, майже завжди trunk-based.

Чого це коштує

Нічого з цього не дається безкоштовно. Trunk-based development працює лише тоді, коли команда спершу побудувала страховку:

• Автоматичні тести, які ганяються на кожній зміні. Якщо зламана зміна може дістатися main, модель розвалюється, бо всі будують на цій спільній лінії. Тести — це підлога під ногами кожного.
• Feature flags, і дисципліна їх використання. Недописане треба ховати охайно, інакше команда знову чекатиме на «великий мердж».
• Пайплайн, який швидко деплоїть і швидко відкочує. Швидке викладання безпечне лише тоді, коли невдалий реліз можна скасувати за хвилини.
• Культура маленьких pull request. Це найважче. Доводиться різати роботу на шматки, які можна переглянути за один раз, і це навичка, яку команда має тренувати.

Компроміс реальний: trunk-based development — найкраща модель для продуктів, що викладаються безперервно: сайтів, вебзастосунків, API, внутрішніх інструментів. Вона погано пасує софту, який випускається номерними версіями і який люди встановлюють, наприклад мобільним застосункам, що проходять перевірку в магазинах. Такі команди зазвичай обирають git flow, де реліз є свідомою подією, а не безперервним потоком.

Trunk-based development проти GitHub flow проти git flow

Trunk-based development — найсуворіший із трьох:

GitHub flow уже каже «мердж у main, коли готово, і одразу деплой». Trunk-based development затягує це до «мердж щонайменше щодня, а недописане ховай за флагами». Повне порівняння GitHub flow і git flow — у статті GitHub flow чи git flow.

Що це означає для продакта

Якщо ваша команда працює trunk-based, у тому, як ви читаєте її апдейти, змінюються три речі:

1. «Змерджено» й далі означає «скоро на сайті» — як у GitHub flow, але ще більшою мірою, бо мерджі відбуваються щодня, а деплой іде автоматично. Не пишіть анонс для фічі одразу після мерджу — спершу перевірте, чи вона за флагом.
2. Feature flags — ваш найкращий друг. Фіча може бути «готова» і змерджена, але невидима для користувачів. Запитуйте «вона за флагом, і коли піде на 100%?» замість «коли вона запуститься?».
3. Моменту релізу немає. Фічі просочуються безперервно. Маркетингові плани, збудовані навколо гучного анонсу нової великої версії, доведеться перебудувати навколо менших, поступових оновлень — або навколо моменту, коли вмикають флаг.

Trunk-based development змінює й розмову про ризики. Замість «чи запрацює цей реліз?» питання стає «якщо ця маленька зміна помилкова, як швидко ми це помітимо й відкотимо?».

Якщо Git для вас узагалі новий, почніть зі статті Git для продакт-менеджерів або одразу з безкоштовного уроку про GitHub flow та уроку про гілки.

Ключові висновки

• Trunk-based development = мердж у main щонайменше раз на день, з маленькими короткоживучими гілками й feature flags для всього недописаного.
• Працює це тому, що малі мерджі означають менше конфліктів, швидше рев'ю і стовбур, який завжди майже готовий до релізу.
• Потребує автоматичних тестів, feature flags, швидких деплоїв і культури маленьких pull request — страховка будується першою.
• Пасує продуктам із безперервним деплоєм (веб, API, внутрішні інструменти), а не номерному софту на кшталт мобільних застосунків.
• Для продакта «змерджено» означає «скоро на сайті», фічі виходять за флагами, а єдиного моменту релізу не існує.

FAQ

Trunk-based development — це те саме, що GitHub flow?

Не зовсім. GitHub flow мерджить кожну зміну в main, коли вона готова; trunk-based development додає щоденний мінімум і скорочує життя гілок до годин. Можна вважати trunk-based development логічним продовженням GitHub flow. Повна картина — у GitHub flow чи git flow.

Чи потрібні feature flags для trunk-based development?

Так, на практиці — так. Правило щоденного мерджу працює лише тоді, коли напівготова робота може безпечно лежати в main, не доходячи до користувачів, і feature flag — стандартний спосіб цього досягти. Без флагів команда скочується назад до довгоживучих гілок, і модель перестає бути trunk-based.

Навіщо мерджити щонайменше раз на день?

Бо вартість мерджу зростає з часом. Гілка, змерджена щодня, мало перетинається з іншими, тож конфлікти лишаються малими, а рев'ю — легкими. Гілка, змерджена раз на тиждень, устигла розійтися з рештою команди — це і є той болісний «великий мердж», якого модель існує, щоб уникнути.

Чи працює trunk-based development для мобільних застосунків?

Зазвичай ні. Мобільні застосунки виходять номерними версіями через перевірку в магазинах, тож реліз — це подія, і оновити всіх користувачів миттєво неможливо. Такі команди зазвичай обирають git flow. Trunk-based development розкривається на продуктах, що деплояться безперервно з main.