6 min lectura • Guide 536 of 877
Gestionando Flujos de Desarrollo Paralelos
Los flujos de desarrollo paralelos para features, releases y hotfixes crean desafíos de coordinación y conflictos de merge. El rastreo aware de branches, gestión de releases y visibilidad multi-flujo de GitScrum ayudan a los equipos a coordinar flujos de trabajo paralelos mientras mantienen calidad de código y evitan conflictos costosos.
Tipos de Flujos de Desarrollo
| Flujo | Propósito | Prioridad | Target de Merge |
|---|---|---|---|
| Main | Features próximo release | Normal | release branch |
| Maintenance | Fixes release actual | Alta | current + main |
| Hotfix | Emergencias producción | Crítica | production + all |
| Experimental | R&D, spikes | Baja | main cuando listo |
Gestión de Flujos Paralelos
ESTRATEGIA DE BRANCHING
GIT FLOW PARA FLUJOS PARALELOS:
┌─────────────────────────────────────────────────┐
│ │
│ production ──●──●──●────────●─────●─────────── │
│ │ ↑ ↑ ↑ │
│ │ │ │ │ │
│ hotfix-1 ────┴─────┘ │ │ │
│ │ │ │
│ release/2.0 ──●──●──●──●─────┘ │ │
│ ↑↑↑↑ │ │
│ ││││ │ │
│ main ──●──●──●──●──●──●──●──●──●───┼──●──●──── │
│ ↑ ↑ ↑ ↑ │ │
│ │ │ │ │ │ │
│ feat-A ─┴──┘ │ │ │ │
│ │ │ │ │
│ feat-B ─────────────┴───┘ │ │
│ │ │
│ release/2.1 ───────────────────────┴─────────── │
│ │
└─────────────────────────────────────────────────┘
DEFINICIONES DE FLUJO:
┌─────────────────────────────────────────────────┐
│ production: Código actual en producción │
│ └── Solo hotfixes mergean aquí directamente │
│ │
│ release/X.X: Estabilización de release │
│ └── Solo bug fixes y polish │
│ │
│ main: Branch de integración │
│ └── Todas las features mergean aquí │
│ │
│ feature/*: Desarrollo de features │
│ └── Merges regulares desde main │
│ │
│ hotfix/*: Fixes de emergencia producción │
│ └── Mergea a production, luego back a main │
└─────────────────────────────────────────────────┘
Organización del Tablero
VISTAS DE TABLERO POR FLUJO PARALELO
VISTA 1: POR FLUJO DE RELEASE
┌─────────────────────────────────────────────────┐
│ Release v2.0 (Actual) │
│ ┌─────────┬──────────┬──────────┬────────┐ │
│ │ To Do │ En Prog │ Review │ Done │ │
│ ├─────────┼──────────┼──────────┼────────┤ │
│ │ [BUG] │ [BUG] │ [FEAT] │ [BUG] │ │
│ │ │ [DOC] │ │ [FEAT] │ │
│ └─────────┴──────────┴──────────┴────────┘ │
│ │
│ Release v2.1 (Próximo) │
│ ┌─────────┬──────────┬──────────┬────────┐ │
│ │ To Do │ En Prog │ Review │ Done │ │
│ ├─────────┼──────────┼──────────┼────────┤ │
│ │ [FEAT] │ [FEAT] │ [FEAT] │ │ │
│ │ [FEAT] │ [FEAT] │ │ │ │
│ │ [TECH] │ │ │ │ │
│ └─────────┴──────────┴──────────┴────────┘ │
│ │
│ Hotfix (Emergencia) │
│ ┌─────────┬──────────┬──────────┬────────┐ │
│ │ To Do │ En Prog │ Review │ Done │ │
│ ├─────────┼──────────┼──────────┼────────┤ │
│ │ │ [HOT] │ │ [HOT] │ │
│ └─────────┴──────────┴──────────┴────────┘ │
└─────────────────────────────────────────────────┘
LABELS PARA RASTREO DE FLUJO:
┌─────────────────────────────────────────────────┐
│ [stream:v2.0] - Trabajo release actual │
│ [stream:v2.1] - Trabajo próximo release │
│ [stream:hotfix] - Emergencia producción │
│ [stream:experimental] - Trabajo R&D │
└─────────────────────────────────────────────────┘
Asignación de Capacidad
CAPACIDAD DEL EQUIPO POR FLUJO
SPLIT DE CAPACIDAD DEL SPRINT:
┌─────────────────────────────────────────────────┐
│ Equipo: 6 desarrolladores │
│ Capacidad sprint: 60 puntos │
│ │
│ Asignación: │
│ ├── v2.1 Features: 40 pts (67%) │
│ │ Developers: @alex, @jordan, @sam, @taylor │
│ │ │
│ ├── v2.0 Mantenimiento: 15 pts (25%) │
│ │ Developers: @casey, @riley │
│ │ │
│ └── Buffer Hotfix: 5 pts (8%) │
│ Developers: Rotación │
└─────────────────────────────────────────────────┘
REGLAS DE PRIORIDAD DE FLUJO:
┌─────────────────────────────────────────────────┐
│ 1. Hotfix: Dejar trabajo actual │
│ 2. v2.0 Crítico: Puede tomar de capacidad v2.1 │
│ 3. v2.1 Features: Prioridad normal │
│ 4. Experimental: Solo si hay capacidad │
└─────────────────────────────────────────────────┘
Coordinación de Merge
COORDINACIÓN DE TIMING DE MERGE
SCHEDULE DE MERGE:
┌─────────────────────────────────────────────────┐
│ Diario: │
│ ├── Feature branches sync DESDE main │
│ └── Hotfixes mergean a producción inmediatamente│
│ │
│ Fin de Sprint: │
│ ├── Features mergean A main │
│ └── Release branch actualizado desde main │
│ │
│ Pre-Release: │
│ ├── Code freeze en release branch │
│ └── Solo fixes críticos permitidos │
└─────────────────────────────────────────────────┘
PROTOCOLO DE CONFLICTO:
┌─────────────────────────────────────────────────┐
│ Si hay conflicto de merge: │
│ 1. Notificar al otro developer │
│ 2. Resolver juntos si área compartida │
│ 3. Testing post-merge │
│ └── Documentar en PR │
│ │
│ Prevención: │
│ ├── Comunicar cambios en código compartido │
│ ├── Merges frecuentes (diarios) │
│ ├── PRs pequeños y enfocados │
│ └── Feature flags para aislamiento │
└─────────────────────────────────────────────────┘
Gestión de Hotfixes
PROTOCOLO DE HOTFIX
═══════════════════
TRIGGER DE HOTFIX:
─────────────────────────────────────
Condiciones:
├── Bug crítico en producción
├── Impacto alto a usuarios
├── No puede esperar a próximo release
└── Severidad P1 o P0
PROCESO:
─────────────────────────────────────
1. Crear tarea con label [stream:hotfix]
2. Branch desde production
3. Fix y testing mínimo necesario
4. Code review expedited
5. Deploy a producción
6. Merge back a main y release branches
TRACKING EN GITSCRUM:
─────────────────────────────────────
├── Swimlane dedicada de Hotfix
├── Notificaciones urgentes
├── Asignación automática a on-call
├── Timer visible de tiempo en fix
└── Post-mortem task creada automáticamente
Soluciones Relacionadas con GitScrum
- Automatización de Gestión de Branches
- Gestión de Releases Grandes
- Feature Flags para Deployments Seguros
- Coordinación Cross-Equipo
Conclusión
Los flujos de desarrollo paralelos son inevitables en equipos que mantienen productos en producción mientras desarrollan nuevas features. GitScrum proporciona la visibilidad y estructura necesarias para coordinar múltiples flujos sin caos, con vistas de tablero por flujo, labels claros, asignación de capacidad visible y protocolos de merge definidos. La clave está en comunicación clara, merges frecuentes y disciplina en branching.