Estrategia de Branches — CIS Latam × Soterex

Date: 2026-07-25 Repositorio: git@github.com:raxardev/soterex.git

Las 3 branches

Branch	Ambiente	Qué dispara
main	Desarrollo (integración)	CI: lint + tests + build, en cada push y PR. No deploya solo.
staging	Sitio de Staging	Deploy automático a Firebase Hosting (staging site/channel) + backend AWS staging, en cada push.
production	App en Producción	Deploy automático a Firebase Hosting (producción) + backend AWS producción, en cada push. Requiere PR aprobado desde staging.

Flujo de trabajo

feature/xxx  →  PR a main  →  (CI corre)  →  merge a main
main         →  PR a staging  →  (CI + deploy a Staging)  →  probar en Staging
staging      →  PR a production  →  (CI + deploy a Producción)

1. Todo el trabajo nuevo sale de main en una branch feature/nombre-corto o fix/nombre-corto.
2. El PR a main corre CI (lint, tests, build de frontend y backend) — no deploya nada.
3. Cuando main está listo para probarse en un ambiente real, se abre PR de main → staging. Al mergear, se dispara el deploy automático a Staging (frontend a Firebase Hosting canal de staging, backend a AWS ambiente de staging).
4. Una vez validado en Staging, PR de staging → production. Al mergear, deploy automático a Producción. Este merge requiere al menos 1 approval (configurar branch protection en GitHub: Settings → Branches → production → Require pull request reviews).

Reglas de protección recomendadas en GitHub (a configurar en el repo)

• main: requiere que pase el workflow de CI antes de mergear.
• staging: requiere que pase CI; no requiere approval humano (es el ambiente de prueba).
• production: requiere CI verde y al menos 1 approval humano. Nadie hace push directo.

Versionado de infraestructura por ambiente

Cada ambiente tiene su propio proyecto de Firebase y su propio set de recursos AWS (nunca se comparte una base de datos o un proyecto de Firebase entre ambientes) — ver doc/environments/dev.md, staging.md, production.md para el detalle de cada uno.