Trunk-Based Development Vocabulary: Feature Flags, Short-Lived Branches, and CI (англійською)
Розробка на основі ствола, короткочасні гілки можливостей, прапорці можливостей для незавершеної роботи і словник постійної інтеграції.
Якщо ви працюєте у команді, яка часто випускає нове програмне забезпечення, ви, ймовірно, чули такі фрази, як « тримайте ваші гілки короткочасними » або « ми використовуємо прапорці можливостей для цього ». Ці ідеї походять з ** розробки на основі ствола **, стратегії гілок, яку підтримують високопродуктивні інженерні команди таких компаній, як Google, Facebook і Netflix. Знання лексики, пов’ язаної з цим потоком робіт, допоможе вам безпечно брати участь у перегляді коду, плануванні спринтів і обговоренні архітектури — незалежно від того, чи вже ваша команда практикує цей процес, чи розглядає можливість його зміни.
Основні терміни
** Розробка на основі гілки** — це процес керування кодом, у якому всі розробники інтегрують свої зміни у єдину спільну гілку (гілка) принаймні раз на день. Метою є зменшення болю від злиття і збереження кодової бази в стані, який можна безперервно випускати.
“Ми перейшли до розробки на основі ствола в минулому кварталі. Конфлікти злиття зменшилися на 80%, тому що ніхто не має гілки старше за день»
«Наші документи про вступ кажуть, що ми практикуємо розробку на основі ствола, але половина команди все ще має гілки функцій, яким два тижні. Нам потрібно про це поговорити»
** Трон (головний / головний) ** — єдина довгожительна гілка, яка представляє поточний, авторитетний стан бази коду. У сучасних репозиторіях він зазвичай називається main; старі проекти все ще можуть називати його master. У будь-якому випадку, гілка - це гілка, в яку кожен розробник щодня зливається і з якої завантажує.
“Завжди тягни з
mainперед тим, як почати працювати. Тут ствол швидко змінюється»
“Ваш PR не може бути об’єднаний доки він не буде перезаснований на останньому стволі. Було ще три злиття цього ранку»
Короткочасна гілка — гілка функціональності або виправлення, яка існує протягом декількох годин або, щонайбільше, протягом одного або двох днів, перш ніж її буде знову об’ єднано з коренем. Чим коротший термін служби, тим менше буде відмінностей і тим легше буде переглядати зміни.
«Ми намагаємося забезпечити короткочасні гілки за допомогою бота, який фіксує все, що старше 48 годин. Це трохи агресивно, але це зберігає відставання відкритих PR-програм управлінськими»
“Я займаюся цим завданням лише один день, а гілка вже стає довгою. Я, ймовірно, повинен розділити його на дві короткочасні гілки і відправити рефактор окремо»
** Тривалість життя гілки можливостей ** — скільки часу існує гілка можливостей до того, як її буде або об’ єднано, або відкинуто. У розробці, заснованій на стволі, команди активно моніторять і мінімізують це число, розглядаючи довгий термін служби як показник ризику, а не ознаку ретельності.
«Яка середня тривалість життя гілки функцій у вашій команді? Наші поширилися на дев’ять днів останнього спринту і наша черга злиття стала кошмаром»
«Зменшення тривалості життя гілок функцій було єдиною зміною, яка найбільше поліпшилася наша частота розгортання»
Інтеграція та злиття словників
** Частота об’ єднання ** — як часто розробник об’ єднує свою роботу у процесі знову у базу даних. Висока частота злиття (кілька разів на день) є відмітною ознакою розробки на основі ствола і сильно корелює з швидшою доставкою і нижчими ступенями інцидентів.
“Я намагаюся підтримувати мою частоту злиття принаймні раз на день. Навіть якщо функція не зроблена, я інтегрую те, що безпечно для корабля»
“В отчете DORA показано, что частота слияний низкая. Ми в середньому 2,3 злиття на інженера на тиждень; елітний еталон ближче до одного разу на день. ”
** Неперервна інтеграція (CI) ** — практика автоматичного збирання і перевірки кожної зміни, об’ єднаної з коренем, зазвичай, за декілька хвилин. Сервери CI, такі як GitHub Actions, CircleCI або Jenkins запускають тестовий набір на кожному затвердженні і повідомляють, чи є збірка зеленою або червоною.
“CI зафіксував виняток нульового вказівника, який ніхто з нас не помітив у перегляді. Це саме та мережа безпеки, яка нам потрібна, перш ніж ми зможемо збільшити частоту злиття»
“Наш конденсаторний трубопровід займає 22 хвилини. Поки ми не отримаємо це нижче 10, інженери не будуть запускати його на кожному затвердженні»
** Вимога щодо зеленого збирання ** — правило команди, за яким жодна зміна не може бути об’ єднана з коренем, якщо всі автоматичні перевірки не пройшли успішно (збірка є « зеленою »). Це забезпечує, що ствол завжди представляє робочий, розгорнутий стан.
“У нас є жорсткі вимоги до зеленого будівництва. Якщо ви пошкодили збірку, ви можете або негайно виправити її, або повернути її. Без винятків»
“Зелене будівництво звучить суворо, але насправді зменшує стрес. Ви ніколи не здогадуєтеся, чи
mainзнаходиться в розгорнутому стані»
** Правила розміру запитів на витягування ** — норми команди або автоматизовані правила, які обмежують кількість рядків коду, які може змінити один PR. Менші PR переглядаються швидше, об’єднуються раніше і несуть менший ризик. Загальне керівництво обмежує PR на 200-400 рядків значущих змін.
“Наша рекомендація щодо розміру PR - 400 рядків макс. Все більше потребує спочатку документації з дизайну і розмови з командою, перш ніж ви напишете код»
“Я помітив, що ваш PR - 1200 рядків. Чи можемо ми розділити міграцію бази даних на її власну PR? Таким чином, рецензенти можуть зосередитись на логіці окремо»
Функціональні прапори і моделі розгалуження
** Прапорець можливості (для незавершеної роботи) ** — параметр налаштування, який надає змогу об’ єднати код незавершеної або експериментальної можливості у основу, залишаючи його невидимим або неактивним для кінцевих користувачів. Також називається перемикач функцій. Замість того, щоб зберігати довготривалу гілку, розробник відправляє темний код за прапорцем і видаляє прапорець, як тільки функція завершена і перевірена.
«Я використовую функціональний прапорець, щоб я міг об’єднати свій напівзавершений платіжний редизайн в
mainбез впливу на виробництво. Прапорець вимкнено для всіх користувачів доки QA не підпишеться»
«Флаги можливостей дозволяють нам відокремити розгортання від випуску. Ми відправляємо код, коли він готовий до відправлення, і ми випускаємо функцію, коли бізнес готовий до випуску»
** Release toggle ** — особливий тип прапора можливості, який використовується для керування тим, чи буде завершена функціональність видимою для користувачів у виробничому режимі. На відміну від прапора роботи в процесі, перемикач випуску навмисно включається як рішення бізнесу або продукту, часто використовується для поступового розгортання або A / B-тестування.
“Функція темного режиму код-завершена і за перемикачем випуску. Маркетинг хоче оголосити про це наступного вівторка, тому ми перевернемо перемикач тоді»
“Ми зберігаємо перемикач випуску в окремому просторі імен конфігурації від прапорців роботи в процесі. Таким чином команда операцій знає, які з них безпечно вмикати без розмови з інженерами спочатку»
** Гілка за абстракцією ** — метод для внесення масштабних змін до кодової бази (наприклад, заміни бібліотеки або перепроектування модуля) без збереження довговічної гілки. Розробник спочатку вводить шар абстракції, за яким можуть сидіти як стара, так і нова реалізація, поступово мігрує виклики, а потім вилучає стару реалізацію і шар абстракції після завершення міграції.
“Ми використовували branch by abstraction, щоб обміняти наш ORM. Міграція тривала три тижні, але кожен запит йшов прямо до
main. Ніхто інший в команді не був заблокований»
«Гілка за абстракцією важче пояснити зацікавленим сторонам, ніж гілка функції, але як тільки ви використовуєте її, ви ніколи не хочете знову управляти тритижневим конфліктом злиття»
** Модель гілок Ship / Show / Ask ** — це легка система прийняття рішень щодо того, як обробляти зміни. * Ship * означає перенесення змін безпосередньо до кореня. * Show * означає створення PR для видимості, але об’ єднання його самостійно без очікування на затвердження. * Ask * означає створення PR і активний запит на перегляд перед об’ єднанням. Команди використовують цю модель, щоб зменшити небажані перегляду вузьких місць, одночасно зберігаючи високоризикові зміни під контролем.
«Ми прийняли модель Ship/Show/Ask і скоротили наш час об’єднання вдвічі. Виправлення помилок і незначні рефакторизації прямують прямо до ствола; нові кінцеві точки API проходять через Ask
“Не впевнений, чи це рахується як Show або Ask - я додаю нову кінцеву точку, але вона добре перевірена і точно відповідає нашому існуючому шаблону. Я позначаю його як Показати і ping команду на Slack»
** Альтернатива заморожування коду ** — стратегія, яку використовують замість зупинки всіх зобов’ язань перед випуском. У розробці, заснованій на стволі, команди уникають традиційних заморожень коду, підтримуючи безперервно випускаємой ствол. Якщо ризикована зміна знаходиться у процесі виконання, її приховують за прапорцем можливості, замість того, щоб блокувати всіх інших від виконання.
“Ми більше не робимо заморожування коду. Якщо щось не готове до випуску, то воно йде за прапором. Всі інші можуть продовжувати перевезення»
“Старий код заморожувався на чотири дні перед кожним випуском. Тепер наш процес випуску займає 20 хвилин і ми відправляємо, коли захочемо»
Monorepo CI — постійна інтеграція, налаштована для одного сховища, яке містить декілька служб або програм. CI Monorepo вимагає ретельного налаштування для запуску тільки тих тестів, які відповідають зміненим шляхам коду, інакше кожен запуск запускає годинний запуск повного набору.
“Ми переїхали в монорепо минулого року. Найскладнішою частиною було налаштування monorepo CI так, щоб зміна платіжної служби не викликала повного перебудови інтерфейсу»
«Nx і Turborepo мають хорошу підтримку для monorepo CI. Вони кешують збудовані артефакти і тільки перезапускають завдання, вхідні дані яких змінилися»
Як використовувати їх у розмові
** Сценарій 1 — Пояснення довгої гілки у стоячі: **
“Я знаю, що моя гілка живе вже три дні, що довше, ніж наша рекомендація. Зміна торкається рівня автентифікації, і я хотів бути обережнішим. Я збираюся розділити його: я з’єднаю абстракцію сьогодні, і фактичний обмін аутентифікацією пройде за прапорцем функції, щоб він міг приземлитися завтра»
** Сценарій 2 — Відкидання великої PR під час перегляду: **
“Це дуже хороша робота, але PR - це 900 рядків. Можемо домовитися про розділ? Я б запропонував спочатку об’єднати зміни моделі домену — ця частина безпечна і самодостатня — а потім продовжити з шаром API у другому PR. Менші відмінності також допомагають нам залишатися в межах наших рекомендацій щодо розміру запитів на скидання»
** Сценарій 3 — Обговорення плану випуску з менеджером продукту: **
“Функція буде кодово завершена до четвертого. Мы отправим его за переключателем. Ви можете обрати, коли перевертати його — це не обов’ язково збігається з нашим розкладом розгортання. Ми також можемо зробити поступове впровадження: 5% користувачів спочатку, а потім 100%, якщо метричні дані виглядають здоровими»
** Сценарій 4 — Введення нового інженера: **
“Ми практикуємо розробку на основі ствола тут. Головне, що вам слід знати: не збільшуйте тривалість життя ваших гілок — ідеально, щоб їх об’ єднання відбувалося у той же день — і переконайтеся, що CI є зеленим перед тим, як ви запитаєте про перегляд. Якщо ви працюєте над чимось великим, скористайтеся прапорцем можливості, а не сидіть на гілці тиждень. Чи є питання щодо моделі Ship/Show/Ask перед тим, як ви відкриєте свій перший PR?»
Краткий справочник
| Term | Plain English Summary |
|---|---|
| Trunk-based development | Everyone integrates into one shared branch, at least daily |
| Short-lived branch | A branch that lives hours, not weeks, before merging |
| Feature flag | A config switch that hides unfinished code from users in production |
| Release toggle | A flag switched on when the business is ready to release a feature |
| Branch by abstraction | Replace a large component incrementally, all on the trunk |
| Continuous integration | Auto-build and test every commit, catch breakage immediately |
| Green build requirement | No merge allowed unless all automated checks pass |
| Ship / Show / Ask | Decision framework: commit directly, show for visibility, or request review |
| Pull request size guideline | Team rule capping how many lines a single PR may change |
| Monorepo CI | CI configured to run only relevant tests in a single multi-service repository |