9 min lectura • Guide 85 of 877
Implementando Flujos de Integración Continua
Integración Continua (CI) transforma cómo equipos validan cambios de código ejecutando automáticamente tests, linting y verificaciones de calidad en cada commit. Cuando CI integra con GitScrum a través de conexiones GitHub, GitLab o Bitbucket, estados de tareas se actualizan automáticamente basados en resultados de build, dando visibilidad al equipo completo sobre salud del código. Esto crea una puerta de calidad que previene código roto de llegar a ramas principales mientras mantiene el tablero sincronizado con estado real de desarrollo.
Fundamentos CI
Por Qué CI Importa
SIN CI:
┌─────────────────────────────────────────────────────────────┐
│ PROBLEMAS VERIFICACIÓN MANUAL │
├─────────────────────────────────────────────────────────────┤
│ │
│ Developer push código: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Funciona en mi máquina" ────────────────────────────────││
│ │ │ ││
│ │ ▼ ││
│ │ ┌───────────────────────────────────────────────────┐ ││
│ │ │ PROBLEMAS DESCUBIERTOS DESPUÉS: │ ││
│ │ │ │ ││
│ │ │ • Versión Node diferente en servidor CI │ ││
│ │ │ • Variable ambiente faltante │ ││
│ │ │ • Test pasa localmente, falla en aislamiento │ ││
│ │ │ • Conflicto merge no resuelto correctamente │ ││
│ │ │ • Dependencia no en package.json │ ││
│ │ │ │ ││
│ │ │ Tiempo debug: Horas a días │ ││
│ │ │ Cambio contexto: Ya en siguiente tarea │ ││
│ │ │ Culpa: "¿Quién rompió el build?" │ ││
│ │ └───────────────────────────────────────────────────┘ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
CON CI:
┌─────────────────────────────────────────────────────────────┐
│ FLUJO VERIFICACIÓN AUTOMATIZADA │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Push │───▶│ CI Ejecuta│───▶│ Resultado │ │
│ │ Commit │ │ Checks │ │ en 5min │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ CHECKS EJECUTAN: │ │
│ │ ✓ Instalar dependencias │ │
│ │ ✓ Lint código │ │
│ │ ✓ Type check │ │
│ │ ✓ Ejecutar unit tests │ │
│ │ ✓ Ejecutar integration tests │ │
│ │ ✓ Build artefacto producción │ │
│ │ │ │
│ │ Todo pasa → ✅ Merge permitido │ │
│ │ Algo falla → ❌ Merge bloqueado │ │
│ └─────────────────────────────────────┘ │
│ │
│ Developer encuentra issue: 5 minutos, no días │
│ Contexto: Aún en la misma tarea │
│ Responsabilidad: Claro qué commit rompió qué │
│ │
└─────────────────────────────────────────────────────────────┘
Etapas Pipeline CI
ESTRUCTURA PIPELINE ESTÁNDAR:
┌─────────────────────────────────────────────────────────────┐
│ ETAPAS PIPELINE │
├─────────────────────────────────────────────────────────────┤
│ │
│ Etapa 1: PREPARAR (1-2 min) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Checkout código ││
│ │ • Cache dependencias ││
│ │ • Instalar paquetes ││
│ │ ││
│ │ Condiciones fallo: Issues red, cache corrupto ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Etapa 2: VALIDAR (2-5 min) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Ejecutar en paralelo: ││
│ │ • Lint (ESLint, Prettier, etc.) ││
│ │ • Type check (TypeScript) ││
│ │ • Auditoría seguridad (npm audit, Snyk) ││
│ │ ││
│ │ Condiciones fallo: Violaciones estilo, errores tipo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Etapa 3: PROBAR (5-15 min) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Secuencial: ││
│ │ • Unit tests ││
│ │ • Integration tests ││
│ │ • E2E tests (opcional por-PR) ││
│ │ ││
│ │ Condiciones fallo: Fallos tests, caída cobertura ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Etapa 4: BUILD (2-5 min) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Build artefacto producción ││
│ │ • Verificar tamaño bundle ││
│ │ • Subir artefactos ││
│ │ ││
│ │ Condiciones fallo: Errores build, límites excedidos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Etapa 5: DEPLOY (en merge a main) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Deploy a staging ││
│ │ • Ejecutar smoke tests ││
│ │ • Notificar equipo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Integración GitScrum
Conectando Proveedores Git
FLUJO GITSCRUM + CI:
┌─────────────────────────────────────────────────────────────┐
│ ACTUALIZACIONES AUTOMÁTICAS TABLERO │
├─────────────────────────────────────────────────────────────┤
│ │
│ Setup: GitScrum → Integraciones → GitHub/GitLab/Bitbucket │
│ │
│ WORKFLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Developer crea branch: ││
│ │ git checkout -b feature/PROJ-123-user-auth ││
│ │ ^^^^ ││
│ │ ID Tarea ││
│ │ ││
│ │ 2. Developer abre PR referenciando tarea: ││
│ │ Título PR: "feat: implement user auth [PROJ-123]" ││
│ │ ││
│ │ 3. GitScrum automáticamente: ││
│ │ • Enlaza PR a tarea PROJ-123 ││
│ │ • Muestra estado PR en tarjeta tarea ││
│ │ • Actualiza tarea basado en estado PR ││
│ │ ││
│ │ 4. CI ejecuta, resultados visibles en GitScrum: ││
│ │ ┌─────────────────────────────────────────────────┐ ││
│ │ │ Tarea: PROJ-123 │ ││
│ │ │ │ ││
│ │ │ 🔗 PR #45: feat: implement user auth │ ││
│ │ │ ⏳ CI Ejecutando: 3 de 5 checks pasados │ ││
│ │ │ │ │ ││
│ │ │ ├─ ✅ lint │ ││
│ │ │ ├─ ✅ typecheck │ ││
│ │ │ ├─ ✅ unit-tests │ ││
│ │ │ ├─ ⏳ integration-tests (ejecutando) │ ││
│ │ │ └─ ⏸️ deploy (esperando) │ ││
│ │ └─────────────────────────────────────────────────┘ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Estado CI visible sin salir del tablero GitScrum │
│ │
└─────────────────────────────────────────────────────────────┘
Automatización Estado Tareas
REGLAS AUTOMATIZACIÓN ESTADO:
┌─────────────────────────────────────────────────────────────┐
│ CONFIGURANDO TRANSICIONES AUTOMÁTICAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ EVENTO │ TRANSICIÓN TAREA ││
│ │───────────────────────────┼─────────────────────────────││
│ │ Branch creado con │ → "En Progreso" ││
│ │ ID tarea │ ││
│ │ │ ││
│ │ PR abierto (draft) │ → "En Progreso" ││
│ │ │ ││
│ │ PR listo para review │ → "Code Review" ││
│ │ │ ││
│ │ CI falló │ → Quedarse en estado actual ││
│ │ │ (agregar label "CI Failed")││
│ │ │ ││
│ │ CI pasó, aprobado │ → "Listo para Merge" ││
│ │ │ ││
│ │ PR merged │ → "Hecho" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Por qué esto importa: │
│ • Tablero siempre refleja realidad │
│ • No se necesitan updates estado manuales │
│ • PM puede ver progreso real sin interrumpir devs │
│ │
└─────────────────────────────────────────────────────────────┘
Puertas de Calidad
Checks Requeridos
CHECKS BLOQUEANTES VS NO-BLOQUEANTES:
┌─────────────────────────────────────────────────────────────┐
│ CONFIGURANDO PUERTAS CALIDAD │
├─────────────────────────────────────────────────────────────┤
│ │
│ DEBE PASAR (bloquea merge): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✓ Lint Sin errores sintaxis, estilo consiste││
│ │ ✓ Type check TypeScript compila sin errores ││
│ │ ✓ Unit tests Todos tests pasan ││
│ │ ✓ Build Build producción exitoso ││
│ │ ✓ Seguridad Sin vulnerabilidades alta/crítica ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DEBERÍA PASAR (advertir pero permitir): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ⚠ Cobertura >80% cobertura (advertir si menor) ││
│ │ ⚠ Tamaño bundle <500KB (advertir si mayor) ││
│ │ ⚠ Rendimiento Lighthouse >90 (advertir si menor) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ INFORMACIONAL (nunca bloquea): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ℹ Updates depend. Sugerencias Dependabot/Renovate ││
│ │ ℹ Complejidad código Métricas mantenibilidad ││
│ │ ℹ Documentación Advertencias JSDoc faltante ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Optimización Pipeline
Mejoras de Velocidad
MEJORES PRÁCTICAS CI RÁPIDO:
┌─────────────────────────────────────────────────────────────┐
│ REDUCIENDO TIEMPO PIPELINE │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. PARALELIZACIÓN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Antes (secuencial): 15 minutos ││
│ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ││
│ │ │Lint │→│Types│→│Unit │→│Integ│→│Build│ ││
│ │ │ 2m │ │ 2m │ │ 5m │ │ 4m │ │ 2m │ ││
│ │ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ ││
│ │ ││
│ │ Después (paralelo): 7 minutos ││
│ │ ┌─────┐ ││
│ │ │Lint │──────────────────────┐ ││
│ │ │ 2m │ │ ││
│ │ └─────┘ ▼ ││
│ │ ┌─────┐ ┌─────────┐ ┌─────┐ ││
│ │ │Types│────────────────▶│ Test │───▶│Build│ ││
│ │ │ 2m │ │ 5m │ │ 2m │ ││
│ │ └─────┘ └─────────┘ └─────┘ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ 2. CACHING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Cachear: ││
│ │ • node_modules (clave: hash de package-lock.json) ││
│ │ • Artefactos build (para archivos sin cambios) ││
│ │ • Snapshots tests ││
│ │ ││
│ │ Cache hit: 2 min install → 10 seg restore ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Prácticas de Equipo
Disciplina CI
ACUERDOS CI EQUIPO:
┌─────────────────────────────────────────────────────────────┐
│ NORMAS CI EQUIPO │
├─────────────────────────────────────────────────────────────┤
│ │
│ ✅ HACER: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Ejecutar tests localmente antes de push ││
│ │ • Arreglar builds rotos inmediatamente ││
│ │ • Mantener pipeline bajo 15 minutos ││
│ │ • Revisar cambios config CI cuidadosamente ││
│ │ • Monitorear tests flaky semanalmente ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ❌ NO HACER: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Push directo a main ││
│ │ • Saltarse CI checks "solo esta vez" ││
│ │ • Dejar builds rojos durante noche ││
│ │ • Ignorar tests fallando saltándolos ││
│ │ • Merge sin review de PR ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PROTOCOLO BUILD ROTO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Todo trabajo para cuando main branch está rojo ││
│ │ 2. Persona que lo rompió toma responsabilidad ││
│ │ 3. Si no arreglable en 10 min, revert y arreglar en rama││
│ │ 4. Postear en Discussions: qué pasó, cómo prevenir ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘