CI/CD y Branch Protection

Las buenas prácticas se imponen técnicamente mediante reglas de protección de ramas y pipelines de CI.

Protección diferenciada por rama

⚙ Settings → Repository → Protected branches → main
Allowed to mergeMaintainers (solo vía MR)
Allowed to pushNadie
Require approvalActivado (mín. 1)
Pipeline must passActivado
⚙ Settings → Repository → Protected branches → testing
Allowed to mergeDevelopers
Allowed to pushDevelopers
Allow force pushDesactivado
Require approvalN/A (no requiere MR)
Pipeline must passRecomendado (no bloqueante)
⚙ Settings → Repository → Protected branches → next / stage
Allowed to mergeMaintainers
Allowed to pushMaintainers
Allow force pushDesactivado
Require approvalN/A (no requiere MR)
Pipeline must passActivado
Justificación de testing: testing es un entorno volátil. Permitir push/merge directo por developers agiliza la integración y validación QA sin dependencias de aprobación para despliegue.

Configuración de Merge Requests

Merge methodSquash commits (solo en main)
Delete source branchActivado
Discussions resolvedActivado

Pipeline de CI mínimo recomendado

Todo MR hacia main (o next/stage) debe pasar el pipeline. Para testing es recomendado pero no bloqueante. El pipeline se configura en .gitlab-ci.yml en la raíz del proyecto.

🧪Tests unitarios e integración: el MR no puede mergearse si fallan.
🔍Linter y análisis estático: garantiza estándares de calidad de código.
🏗️Build exitoso: verifica que la aplicación construye sin errores.