Коротко — нет "универсального" рецепта. В реальной команде 5+ человек хорошо работает trunk‑based (main всегда деплойбл) с короткими ветками, обязательными PR и фичфлагами; Git‑flow с длительными ветками даёт много конфликтов и тормозит быстрые хотфиксы. Ниже — практические правила и приёмы, которые реально снижают инциденты, конфликты миграций и локализаций.
1) Общее правило ветвления и релизов
- Запрещаем пуши прямо в main: защищённый main, обязательный PR + CI, минимум 1–2 ревьюера.
- Короткие фич‑ветки (hours–days, максимум ~1 неделя). Длинные ветки — плохо.
- Каждая осмысленная фича/фикс — своя ветка и PR. Не коммитить «много фич в main» — это убивает откат и ревью.
- Feature flags для недоделанных или ризиковых фич: можно слить код в main, но выключить поведение.
- Релизы: main автоматически деплоится (CD), либо у вас «релизные теги» из main. Для срочного хотфикса — ветка hotfix от прод‑тега/commit, фикс → PR → сразу в main и в prod, затем влить назад в основную ветку разработки (если у вас develop, то туда тоже).
2) Почему trunk‑based предпочтительнее Git‑flow в вашей ситуации
- Git‑flow хорош для редких релизов, но в командах с частыми изменениями и срочными хотфиксами он создаёт долгоживущие мёрджи и конфликты.
- Trunk‑based + feature flags + CI + канаре/blue‑green даёт быстрые безопасные деплои и простые откаты.
3) Про PR‑ы и granular‑коммиты
- Каждой значимой фиче/фиксу — своя ветка и PR. Это улучшает ревью, CI‑проверки, трассируемость и откат.
- Маленькие/атомарные PR проще тестировать и реже ломают проду. Рекомендуется PR < 400–500 строк изменений.
- Нельзя мерджить в main без успешного CI, тестов, миграций (если есть), и прохода ревью.
4) Как работать с миграциями БД (чтобы не было конфликтов и инцидентов)
- Принцип backward/forward compatible миграций: «expand → migrate → contract».
- Сначала добавить nullable/новое поле/индекс; обновить код писать в оба поля; запустить бэкап/фоновую миграцию и тесты; потом удалить старое поле/констрейнт в отдельном релизе.
- Один PR — одна логическая миграция (или несколько мелких, если они связаны). Не заставляйте в одном PR несколько несвязанных миграций.
- Генерация миграций:
- Используйте timestamp/UUID в имени миграции (чтобы не было конфликтов по номерам).
- Блокировки: используйте механизм контроля в миграторе (flyway/liquibase/ale mbic/rails), который предотвращает одновременное выполнение миграций.
- CI должен запускать миграции на чистой БД (up + down) чтобы ловить ошибки.
- Код и миграция в одном PR или в двух? Практики разные:
- Если миграция совместима (add column), можно в одном PR.
- Для опасных изменений — split: сначала миграция без изменения поведения, в следующем PR — использование поля/индекса. Это снижает риск.
- Координация изменений таблиц:
- Внутри команды договоритесь, кто «владеет» табличной схемой / назначьте DB‑owner для ревью миграций.
- Наличие багтрекера/issue для «табл‑изменений» с пометкой «может конфликтовать» и очерёдностью.
- На проде:
- Запускайте миграции в транзакциях (если БД поддерживает) или делайте non‑blocking операции (CREATE INDEX CONCURRENTLY в Postgres).
- Всегда делайте бэкап и возможность отката (скрипт down).
- Тестирование миграций: CI, staging с похожим объёмом данных, прогон фоновых задач и проверка производительности.
Пример паттерна изменения колонки (rename):
1. PR1: добавить новую колонку new_col nullable, код пишет в обе колонки. Мёрдж → деплой.
2. Миграция/бэкап данных, постепенно копируем old->new.
3. PR2: переключаем чтение на new_col (пишем в обе). Мёрдж → деплой.
4. PR3: удалить old_col (drop) в отдельном релизе.
5) Локализации — как избежать конфликтов
- Разделяйте локализационные файлы по компонентам/модулям (не один огромный translations.json для всего проекта). Мелкие файлы реже конфликтуют.
- Используйте ключ‑бэйсед сообщения (message keys), а не целые строки в коде. Тогда переименования проще согласовывать.
- Используйте платформу перевода (Crowdin, Lokalise и т. п.) — храните исходники ключей в репозитории, переводы в сервисе, синхронизируйте через CI. Это снимает конфликтность .po/.json файлов.
- Если используете PO/POEdit — msgmerge умеет аккуратно слить изменения. CI может запускать авто‑merge для чистых случаев.
- Принцип: обновление базовых ключей — в PR вместе с кодом; переводчики получают пул изменений отдельно. Не держите в коде сгенерированные большие переводные файлы, лучше хранить шаблон и подтягивать переводы в CI/deploy.
- Формат файлов: один ключ — одна строка; flattened JSON/YAML удобнее для мерджа (меньше конфликтов из‑за форматирования).
6) Про практики, которые снижают инциденты (и про пятничные релизы)
- Не деплойте крупные изменения в пятницу вечером. Установите "код замораживается" с риском — до понедельника или только маленькие хотфиксы.
- Используйте canary/rolling/blue‑green деплой: сначала мелкая доля трафика, мониторинг, затем масштаб.
- Feature flags дают быстрый откат: выключил флаг — и проблема исчезла без отката всех деплоев.
- Автоматический мониторинг + ранние алерты + runbook для быстрого отключения фич/катов.
- Обучение oncall и шаблоны отката: rollback git tag или репозиторий артефактов, а не ручной revert на prod.
7) Инструменты и конфигурации CI/CD, которые помогают
- Protected main, required checks: unit tests, integration tests, migration dry‑run, linter, security scan.
- Автоматические миграции в CI на ephemeral БД, прогон тестов миграций.
- Pre‑merge hooks: проверка конфликтов миграций (две разные миграции на одну таблицу в одном PR — warning).
- Автоматическое форматирование/merge для локализаций, либо бот, который создаёт PR с мерджем переводов.
- Используйте codeowners: DB‑schema files и translations требуют владельца ревью.
8) Рекомендации по процессу в команде 5+
- Документируйте правила: ветвление, миграции, локали, деплой политика (включая запрет больших релизов в пятницу).
- Короткие ежедневные синки/standups или sync‑канал для миграций/изменений схемы.
- Назначьте «schema owner» — человек, который ревьюит все миграции и следит за порядком.
- PR templates: указывайте есть ли миграция, есть ли изменение локализации, нужно ли feature flag.
- Пост‑мортемы после инцидентов и обновление процесса.
Короткий чеклист для внедрения прямо сейчас
- Запрет на прямые пуши в main + требование PR + CI.
- Стратегия: trunk‑based + короткие ветки + feature flags.
- Каждая миграция — отдельный PR; имена миграций с timestamp; CI запускает миграции на чистой БД.
- Локали по компонентам + переводческая платформа или авто‑merge через msgmerge.
- Канаре/blue‑green, мониторинг и правило «никаких крупных деплоев в пятницу».
Если хотите, могу:
- Сформировать PR‑шаблон и CI‑checklist для вашей команды.
- Написать пример политики миграций (markdown) для внутреннего Confluence/README.