Вступ:
Розробка на основі стовбуру (Trunk) не є новою моделлю розгалуження. Слово «стовбур» відноситься до поняття зростаючого дерева, де найтовстішим і найдовшим прольотом є стовбур, а не гілки, які радіально відходять від нього та мають меншу довжину. З середини дев’яностих це була менш відома розгалужена модель вибору, а з вісімдесятих її розглядали тактично. Найбільші організації-розробники, такі як Google (як згадувалося) і Facebook, масштабно практикують це. За 30 років різні досягнення технологій керування джерелами та пов’язаних інструментів/технік зробили trunk-розробку більш (іноді менш) поширеною, але це була розгалужена модель, якої багато хто дотримувався протягом багатьох років.
Спільні гілки за межами основної/Trunk лінії погані при будь-якій частоті випуску:
Розробка на основі Trunk для невеликих команд:
Масштабована Trunk-Розробка:
Розробка, Твердження та Застереження::
Розробка на основній гілці є ключовим чинником Безперервної Інтеграції та Безперервної Доставки. Коли члени команди надсилають свої зміни в основну гілку кілька разів на день, це полегшує дотримання основної вимоги безперервної інтеграції, а саме - всі члени команди мають надсилати зміни в основну гілку принаймні раз на 24 години. Це забезпечує постійну готовність кодової бази до випуску і сприяє реалізації безперервної доставки.
Розмежування між Trunk-Based Development для невеликих команд і масштабованою розробкою на основі Trunk-Based Development залежить від розміру команди та частоти комітів. Точний момент, коли команда розробників перестає бути “невеликою” і переходить до “масштабної”, є предметом обговорення практиків. Незалежно від цього, команди виконують повну збірку (компіляцію, модульні тести, інтеграційні тести) на своїх робочих станціях перед тим, як здійснити коміт або пуш, щоб інші (або боти) могли їх бачити.
Твердження
- Варто обрати Trunk-Based Development замість GitFlow та інших моделей з великою кількістю довготривалих гілок.
- Ви можете або комітити/пушити безпосередньо в основну гілку (для дуже маленьких команд), або використовувати workflow з Pull-Request, за умови, що ці фічеві гілки короткотривалі і створені однією особою.
Застереження
- Залежно від розміру команди та кількості комітів, короткострокові гілки функцій використовуються для перегляду коду та перевірки збірки (CI), але не для створення чи публікації артефактів, які відбуваються до того, як коміти потраплять у стовбур, щоб інші розробники могли не залежати від них. Такі гілки дозволяють розробникам активно та безперервно переглядати код внесків до того, як їхній код буде інтегровано в основну гілку. Дуже невеликі команди можуть здійснювати прямі коміти в стовбур.
- Залежно від передбачуваної частоти випуску, можуть існувати гілки релізу, які витягуються із стовбуру своєчасно, «зміцнюються» перед випуском (це не є командною діяльністю), і ці гілки через деякий час видаляються після релізу. Крім того, також може не бути гілок релізу, якщо команда робить реліз зі Trunk та вибирає стратегію «виправлення вперед» для виправлення помилок. Реліз зі стовбуру також актуальний для високопродуктивних команд.
- Команди повинні довше освоювати пов’язану гілку за допомогою техніки абстрагування, щоб досягти змін, і використовувати позначки функцій у повсякденній розробці, щоб забезпечити хеджування (hedging) порядку випусків (а також інші хороші поради – дивіться в одночасній розробці послідовних випусків").
- Якщо у вас є більше ніж пара розробників у проекті, вам потрібно буде підключити сервер збірки, щоб переконатися, що їхні коміти не зламали збірку після того, як вони потраплять у стовбур, а також коли вони будуть готові до об’єднання назад у стовбур із короткочасної гілки функції.
- Команди розробників можуть збільшуватись або зменшуватись у розмірах (у стовбурі), не впливаючи на пропускну здатність або якість. Доказ? Google використовує Trunk-Based Development і має 35 000 розробників і автоматизаторів контролю якості в цьому єдиному стовбурі монорепозиторію, який у їхньому випадку може розширюватися або скорочуватися відповідно до розробника.
- Люди, які практикують модель розгалуження GitHub-flow, відчують, що це дуже схоже, але є одна невелика різниця навколо того звідки робити реліз.
- Люди, які практикують модель розгалуження Gitflow, побачать, що це зовсім інше, як і багато розробників, які звикли до популярних моделей розгалуження минулого ClearCase, Subversion, Perforce, StarTeam, VCS.
- Багато публікацій пропагують Trunk-Based Development так, як ми її тут описуємо. До них належать бестселери «Continuous Delivery» і «DevOps Handbook». Тому це точно більше не повинно викликати суперечок!
Короткий підсумок
Модель розгалуження з керуванням вихідним кодом, де розробники співпрацюють над кодом в одній гілці під назвою «Trunk», протистоїть будь-якому тиску щодо створення інших довготривалих гілок розробки, використовуючи задокументовані методи. Тому вони уникають проблем злиття, не руйнують збірку та живуть довго і щасливо.