Среды и версионирование

Два контура

Контур	Ветка	Где работает	Назначение
prod	main	Прод-хост, по ночному расписанию	Стабильный; всякое изменение приезжает осознанным промоушеном
dev	dev	Локальный dev-стек (Docker: Postgres, Redis, API, web)	Интеграция; вся повседневная работа сначала попадает сюда

Поток однонаправленный: фиче-ветки мержатся в dev мелкими PR; промоушен в main — отдельный, явно одобряемый шаг; деплой на прод-хост — отдельный скрипт после него. Хотфикс, вынужденно попавший в main напрямую, в той же сессии переносится в dev — main всегда подмножество dev.

Версионирование — две независимые оси

Ось A: модули платформы. Каждый модуль (platform, webui, contracts, сервисы, этот портал) версионируется по SemVer независимо, версии выводятся автоматически из истории коммитов — руками их не бампают. Зонтичная версия платформы отслеживает целое.

Ось B: версии пайплайнов. Collect, Generate и Localize версионируются отдельно в каталоге пайплайнов — с неизменяемыми директориями кода и пинами на контракт. Эта ось движется своим темпом: пайплайн может уйти на несколько версий вперёд внутри одного релиза платформы, и наоборот. См. Жизненный цикл версий.

Оси расцеплены сознательно: деплой платформы не меняет, какую версию пайплайна исполняет флот, а промоушен версии пайплайна не требует релиза платформы.

Что здесь значит «релиз»

• Смержено в dev — интегрировано, прошло гейт (линт, типы, тесты — локальный прогон как гейт мержа), пользователю ещё не видно.
• Промоушен в main + деплой — работает на прод-хосте.
• Включено — жёсткое правило платформы: фича считается задеплоенной, только когда она включена и её эффект наблюдаем (метрика, страница, число). Код за выключенным флагом в отчётах и документации — явно не «задеплоено».