Настройка Git-репозитория и бранчинг-стратегии (Trunk-Based Development)

Настройка Git-репозитория и бранчинг-стратегии (Trunk-Based Development)

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

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

Почему долгоживущие ветки — это риск, а не безопасность

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

С TBD эта боль распределяется равномерно и становится управляемой: маленькие конфликты каждый день вместо большого конфликта раз в две недели. Мы гарантируем: после перехода на 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. Адаптация команды — от нескольких недель. Стоимость рассчитывается индивидуально: оценим ваш проект — напишите нам. Наши инженеры имеют сертификаты и 5+ лет опыта в DevOps-трансформации. Гарантируем: переход на TBD снизит конфликты на 70% и ускорит CI в 2-3 раза.

Как внедрить TBD в существующем проекте?

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

Почему TBD лучше Git Flow в 2-3 раза?

По нашим замерам, после перехода на TBD:

• Время от коммита до деплоя сокращается на 60%
• Частота конфликтов снижается на 70-80%
• Удовлетворённость разработчиков процессом растёт на 40%

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