Toutsu/GmRelayBot
1
1
Fork 0
Code Issues 18 Pull Requests 1 Actions 1 Packages Projects Releases 85 Wiki Activity

infra: staging окружение и стратегия rollback образов #59

New Issue
Open
opened 2026-05-12 13:25:49 +03:00 by Toutsu · 0 comments
Toutsu commented 2026-05-12 13:25:49 +03:00
Owner
Copy Link
Copy Source

Проблема

Деплой выполняется напрямую из ветки main через .gitea/workflows/deploy.yml. Нет отдельного стейджинг-окружения для проверки перед боем. Если сломанный код попадает в main, он немедленно разворачивается в production. Откат на предыдущую версию требует ручного поиска предыдущего тега образа.

Критичность

  • Zero isolation: баг в merged PR мгновенно влияет на реальных пользователей.
  • Нет механизма отката: docker compose up не знает о "предыдущей рабочей версии".

Предлагаемое решение

1. Staging-конвейер

  • Создать ветку release/staging (или staging).
  • Workflow deploy-staging.yml — триггер на push в release/staging.
  • Staging использует отдельный compose.staging.yaml (другой GMRELAY_WEB_PORT, другие volume-имена, отдельная БД gmrelay_staging_db).

2. Production-конвейер

  • Production deploy — только на push тега v* (или manual trigger).
  • Перед deploy pull staging-образа и дополнительный smoke-тест.

3. Rollback

  • Хранить в Gitea Container Registry последние 3 тега версий.
  • Скрипт scripts/rollback.sh <version> делает docker compose pull на указанный тег и up -d.
  • Добавить docker compose override для возможности указать VERSION через .env.

Критерии приёмки

  • release/staging деплоится в отдельное окружение без влияния на прод.
  • Production deploy выполняется только по тегу v*.
  • scripts/rollback.sh v1.13.0 успешно откатывает оба образа (bot + web) на указанную версию.
  • Документирована процедура экстренного отката в README.

Связь

Этап: Подготовка к production

## Проблема Деплой выполняется напрямую из ветки `main` через `.gitea/workflows/deploy.yml`. Нет отдельного стейджинг-окружения для проверки перед боем. Если сломанный код попадает в `main`, он немедленно разворачивается в production. Откат на предыдущую версию требует ручного поиска предыдущего тега образа. ## Критичность - **Zero isolation**: баг в merged PR мгновенно влияет на реальных пользователей. - **Нет механизма отката**: `docker compose up` не знает о "предыдущей рабочей версии". ## Предлагаемое решение ### 1. Staging-конвейер - Создать ветку `release/staging` (или `staging`). - Workflow `deploy-staging.yml` — триггер на push в `release/staging`. - Staging использует отдельный `compose.staging.yaml` (другой `GMRELAY_WEB_PORT`, другие volume-имена, отдельная БД `gmrelay_staging_db`). ### 2. Production-конвейер - Production deploy — только на push тега `v*` (или manual trigger). - Перед deploy pull staging-образа и дополнительный smoke-тест. ### 3. Rollback - Хранить в Gitea Container Registry последние 3 тега версий. - Скрипт `scripts/rollback.sh <version>` делает `docker compose pull` на указанный тег и `up -d`. - Добавить `docker compose` override для возможности указать `VERSION` через `.env`. ## Критерии приёмки - [ ] `release/staging` деплоится в отдельное окружение без влияния на прод. - [ ] Production deploy выполняется только по тегу `v*`. - [ ] `scripts/rollback.sh v1.13.0` успешно откатывает оба образа (bot + web) на указанную версию. - [ ] Документирована процедура экстренного отката в README. ## Связь Этап: **Подготовка к production**
Toutsu added this to the Подготовка к production milestone 2026-05-12 13:25:49 +03:00
Toutsu added the priority:p0 label 2026-05-12 13:25:49 +03:00
Toutsu modified the milestone from Подготовка к production to Этап — Тестовая инфраструктура / Staging 2026-05-13 22:30:16 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:bot
Telegram bot and worker logic
 area:data
Database schema, migrations and persistence model
 area:discord
Discord bot service and Discord adapter
 area:infra
Infrastructure, runtime and deployment
 area:miniapp
Telegram Mini App dashboard
 area:platform
Platform-neutral abstractions and adapter boundaries
 area:shared
Shared domain and rendering contracts
 area:web
Blazor web dashboard
 in-progress
В работе (issue взят агентом)
 next-up
Recommended immediate backlog
 pending-approval
Ждёт согласования плана решения
 platform:discord
Discord-specific behavior or adapter work
 platform:multi
Cross-platform or platform-neutral work
 platform:telegram
Telegram-specific behavior or adapter work
 priority:p0
Critical priority
 priority:p0
Блокирующий приоритет: задача должна быть выполнена до признания решения production-ready
 priority:p1
High priority
 priority:p2
Medium priority
 priority:p3
Lower priority
 security
Security-sensitive work
 type:bug
Bug fix or corrective work
 type:chore
Maintenance and supporting work
 type:feature
New product functionality
 type:refactor
Structural change without direct feature growth
 type:test
Testing and coverage work
No Label priority:p0
Milestone
No items
No Milestone Этап — Тестовая инфраструктура / Staging
Projects
Clear projects
No project
Assignees
Clear assignees
Toutsu
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Toutsu/GmRelayBot#59
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?