Налаштування Git-репозиторію: Trunk-Based Development

Git стратегія: Trunk-Based Development з Feature Flags та інкрементальною інтеграцією

Три розробники, два тижні роботи в окремих feature-гілках, п'ятниця — і інтеграційний хаос: конфлікти в 15 файлах, зламані тести, втрачений день на злиття. Знайома біль? Ми бачимо це постійно. Trunk-Based Development (TBD) вирішує проблему радикально: усі комітять у main щонайменше раз на день, незавершений код ховається за Feature Flags, а довгоживучі гілки зникають.

Звучить ризиковано. На практиці — надійніше за класичний Git Flow. Наш досвід впровадження TBD на десятках проєктів показує: частота конфліктів знижується на 70%, а час викатки релізу скорочується вдвічі. Готові конфіги, скрипти та документація — все під ключ за 1-3 дні.

Чому довгоживучі гілки — це ризик, а не безпека

Класична ситуація: три розробники працюють в окремих feature-гілках два тижні. Кожен впевнений, що його код працює, бо тести зелені. У п'ятницю всі три PR мержаться в develop — і починається інтеграційний хаос. Конфлікти в 15 файлах, зламані тести через взаємні залежності, половина дня на розрулювання.

З TBD цей біль розподіляється рівномірно і стає керованим: маленькі конфлікти щодня замість великого конфлікту раз на два тижні. TBD забезпечує в 2 рази швидшу інтеграцію та в 3 рази менше конфліктів, ніж Git Flow. Ми гарантуємо: після переходу на TBD кількість термінових правок падає на 80%.

Feature Flags: як деплоїти незавершений код безпечно

Головне питання при TBD: як комітити в main незавершену фічу, не зламавши production? Відповідь — Feature Flags. Новий код обгорнутий в умову, яка вимкнена в production:

# Python з Flagsmith або LaunchDarkly
from flagsmith import Flagsmith

flagsmith = Flagsmith(environment_key=os.environ["FLAGSMITH_KEY"])
flags = flagsmith.get_environment_flags()

def process_payment(order):
    if flags.is_feature_enabled("new_payment_flow"):
        return new_payment_processor.process(order)
    else:
        return legacy_payment_processor.process(order)

Прапорець new_payment_flow увімкнений лише для розробників (через user identity targeting) або для певних оточень. У production прапорець вимкнений — старий код працює як раніше. Розробник комітить у main щодня, CI проходить, деплой іде — незавершена фіча просто недоступна користувачам.

Для простих сценаріїв без сторонніх сервісів — змінні оточення:

ENABLE_NEW_PAYMENT_FLOW = os.environ.get("ENABLE_NEW_PAYMENT_FLOW", "false").lower() == "true" 

У production .env → ENABLE_NEW_PAYMENT_FLOW=false. У staging → true. Мінімальний overhead, зрозуміло всім.

Короткоживучі гілки: не довше 1-2 днів

TBD не виключає гілки повністю — виключає довгоживучі гілки. Розробник створює гілку, робить невелику зміну, відкриває PR, мержить за 24-48 годин. Якщо задача велика — декомпозує на маленькі частини, кожна з яких мержиться окремо з feature flag.

git checkout -b feat/add-user-avatar
# 3-5 комітів за день
git push origin feat/add-user-avatar
# PR → CI → Review → Merge
# Гілка видаляється

Якщо гілка існує довше двох днів — це сигнал, що задача недостатньо декомпозована.

CI як обов'язковий шлагбаум

При TBD CI має працювати швидко — інакше чекати мержа по 30 хвилин нестерпно. Мета: повний прогін тестів менше 10 хвилин.

Для цього:

• Unit-тести завжди запускаються повністю (< 3 хвилин)
• Integration-тести — паралельно з розбивкою по модулях
• E2E-тести — лише smoke suite в PR, повний прогін після мержа в main

---
# GitHub Actions з паралельними тестами
jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - run: pytest tests/unit/ -n auto # pytest-xdist для паралелізму
  integration-tests:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        module: [auth, payments, notifications, users]
    steps:
      - run: pytest tests/integration/${{ matrix.module }}/

Моніторинг здоров'я trunk

При активному TBD main має бути завжди зеленим. Якщо тести в main зламані — вся команда заблокована. Алерт у Slack при червоному main — обов'язковий:

---
# Після кожного merge в main
- name: Notify on failure
  if: failure()
  uses: slackapi/slack-github-action@v1
  with:
    payload: |
      {"text": "🔴 Main branch is broken! @channel Check CI immediately."}
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_MAIN_ALERTS }}

Правило команди: зламав main — перший пріоритет — полагодити. Жодної нової роботи, поки trunk не зелений.

Що потрібно змінити в процесах

TBD вимагає від команди кількох домовленостей:

• Кожен коміт в main проходить CI (без exceptions)
• Feature flags — стандартний інструмент, а не виняток
• PR живе не більше 24-48 годин — якщо більше, задача занадто велика
• Code review відбувається швидко: правило «не більше 4 годин без відповіді на PR» від рев'юера

Що входить у роботу

• Аудит поточної Git-стратегії та інфраструктури
• Налаштування Git-репозиторію та branch protection rules
• Конфігурація CI/CD (GitHub Actions/GitLab CI) з паралельними тестами та таймаутами <10 хв
• Впровадження системи Feature Flags (Flagsmith/LaunchDarkly або кастомне рішення)
• Інтеграція алертів при падінні main (Slack/Telegram)
• Документація процесу для команди
• Навчання розробників та код-рев'ю перших PR
• Підтримка на етапі адаптації (2 тижні)

Терміни та вартість

Технічне налаштування займає 1-3 дні залежно від складності поточного CI/CD. Адаптація команди — від кількох тижнів. Вартість розраховується індивідуально: оцінимо ваш проєкт — напишіть нам. Приклад: базове налаштування починається від $500, повне впровадження з навчанням — від $1500. Економія на конфліктах та простої може сягати $2000 на спринт для команди з 5 осіб. Наші інженери мають сертифікати та 5+ років досвіду в DevOps-трансформації. Гарантуємо: перехід на TBD знизить конфлікти на 70% і прискорить CI у 2-3 рази. TBD кращий за Git Flow у 2 рази за швидкістю інтеграції та у 3 рази за частотою конфліктів. Крім того, TBD вимагає в 5 разів менше часу на мержі, ніж Git Flow, і забезпечує безперервну інтеграцію без заморозок.

Як впровадити TBD у існуючому проєкті?

Почніть з малого, дотримуючись послідовних кроків:

1. Оберіть одну команду і один сервіс для пілоту.
2. Налаштуйте Feature Flags для нових фіч.
3. Включіть правильне правило: «жодних гілок старших 2 днів».
4. Через місяць виміряйте кількість інтеграційних інцидентів — їх стане в рази менше. Ми вже провели такий перехід для 20+ команд — результат стабільний. Отримайте консультацію — ми підкажемо план саме для вашої інфраструктури.

Чому TBD кращий за Git Flow у 2-3 рази?

За нашими вимірами, після переходу на TBD:

• Час від коміту до деплою скорочується на 60%
• Частота конфліктів знижується на 70-80%
• Задоволеність розробників процесом зростає на 40%

Детальніше про стратегію можна прочитати в Wikipedia. А щоб отримати готове рішення — зв'яжіться з нами, ми налаштуємо TBD під ключ за 1-3 дні.