Branching Strategy
Стратегия ветвления для безопасного деплоя в production.
1. Summary
Используется двухветочная модель: staging (разработка) → main (production). Все изменения попадают в production только через Pull Request.
2. Ветки
| Ветка | Назначение | Деплой |
|---|---|---|
main | Production-ready код | Dokploy автодеплой при push |
staging | Активная разработка | Dokploy автодеплой на staging VPS |
docs-build | Артефакты документации (build, api-docs, specs) | GitHub Actions собирает при push в main → push --force в docs-build → Dokploy webhook → docs.goloot.online |
Workflow
1. Работаешь в staging (или feature-ветках от staging)
2. Пушишь в staging → Dokploy деплоит на staging VPS
3. Готов к релизу → создаёшь PR: staging → main
4. Merge PR → Dokploy деплоит в production
3. Branch Protection
Настроенные правила (GitHub Ruleset: protect-main)
| Правило | Статус | Описание |
|---|---|---|
| Require a pull request before merging | ON | Нельзя пушить в main напрямую, только через PR |
| Restrict deletions | ON | Нельзя удалить ветку main |
| Block force pushes | ON | Нельзя перезаписать историю main |
| Required approvals | 0 | Один разработчик — self-merge |
Правила НЕ enforce-ятся на бесплатном плане
GitHub не применяет рулсеты на private-репозиториях с бесплатным (Personal) аккаунтом. Для фактической блокировки нужен GitHub Team ($4/мес) или public repo.
Текущий статус: правила созданы, но работают как конвенция — технически прямой push в main возможен. Защита основана на дисциплине разработчика.
Миграция: при переходе на GitHub Team рулсеты автоматически начнут работать без дополнительной настройки.
4. Процесс релиза
Стандартный релиз
# 1. Убедиться что staging актуален
git checkout staging
git pull origin staging
# 2. Создать PR через GitHub UI или CLI
gh pr create --base main --head staging \
--title "Release: описание" \
--body "## Changes\n- feature A\n- fix B"
# 3. Merge PR в GitHub UI
# → Dokploy автоматически деплоит
Hotfix (экстренное исправление)
# 1. Ветка от main
git checkout -b hotfix/critical-bug main
# 2. Исправить
# 3. PR: hotfix → main (деплой)
# 4. Merge hotfix в staging тоже (чтобы не потерять)
git checkout staging
git merge hotfix/critical-bug
git push origin staging
5. Что нельзя делать
| Действие | Почему нельзя |
|---|---|
git push origin main | Обходит PR review, нет контроля что деплоится |
git push --force origin main | Перезапишет историю, может сломать деплой |
| Работать напрямую в main | Staging существует для изоляции разработки от production |
| Мержить staging → main без проверки | Убедись что type-check и lint проходят |
6. Staging Environment
Два раздельных VPS — полная изоляция staging от production.
Инфраструктура
| Компонент | Production (VPS 1) | Staging (VPS 2) |
|---|---|---|
| Ветка | main | staging |
| БД | Отдельная PostgreSQL | Отдельная PostgreSQL |
| Telegram Bot | @goLootBot (prod) | Отдельный staging бот |
| Dokploy | Автодеплой из main | Автодеплой из staging |
Субдомены
| Сервис | Production | Staging |
|---|---|---|
| Frontend | goloot.online | staging.goloot.online |
| Admin | admin.goloot.online | staging.admin.goloot.online |
| API | api.goloot.online | staging.api.goloot.online |
DNS: A-записи staging.* → IP staging VPS.
Что раздельное (обязательно)
| Ресурс | Почему |
|---|---|
| PostgreSQL | Миграции на staging не должны ломать prod данные |
| Telegram Bot | Webhook-и не должны пересекаться |
| ENV переменные | Разные DATABASE_URL, BOT_TOKEN, API ключи |
Что общее
| Ресурс | Почему |
|---|---|
| GitHub репо | Один репо, разные ветки |
| Docker конфиг | Те же Dockerfiles, разные ENV |
| Prisma schema | Одна schema, разные БД |
Related
- CI/CD Setup — автодеплой через Dokploy и GitHub Actions
- Overview — общая архитектура