6 min lectura • Guide 624 of 877
Mejores Prácticas de Pipeline CI/CD
Los pipelines CI/CD bien diseñados aceleran la entrega sin sacrificar calidad al detectar problemas en la etapa más temprana posible. La integración de GitScrum con herramientas de pipeline proporciona visibilidad del estado de build, resultados de tests y progreso de deployment, ayudando a los equipos a coordinarse alrededor de sus procesos de entrega automatizada.
Principios de Diseño de Pipeline
Velocidad vs Rigurosidad
OPTIMIZACIÓN DE ETAPAS DEL PIPELINE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FEEDBACK RÁPIDO PRIMERO: │
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ Lint │→│ Unit │→│ Build │→│ Int. │→│ E2E │ │
│ │ (30s) │ │ (2m) │ │ (3m) │ │ (10m) │ │ (20m) │ │
│ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘ │
│ ↓ ↓ ↓ ↓ ↓ │
│ Falla Falla Falla Falla Falla │
│ rápido rápido medio más lento más lento │
│ │
│ PRINCIPIO: Detectar problemas baratos antes de checks caros│
└─────────────────────────────────────────────────────────────┘
Ejecución Paralela
ESTRATEGIA DE PARALELIZACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SECUENCIAL (lento): PARALELO (rápido): │
│ │
│ Lint ──→ Unit ──→ Build ┌── Lint ──┐ │
│ 5m 3m │ │ │
│ ├── Unit ──┼── Build ──→ │
│ Total: 8 minutos │ 2m │ 3m │
│ └── Type ──┘ │
│ Check │
│ Total: 5 minutos │
│ │
│ CANDIDATOS PARA PARALELO: │
│ • Linting + Type checking + Security scan │
│ • Tests unitarios entre módulos │
│ • Tests de integración por servicio │
│ • Tests E2E por área de funcionalidad │
└─────────────────────────────────────────────────────────────┘
Confiabilidad del Pipeline
Manejo de Fallas
PATRONES DE MANEJO DE FALLAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FALLAR RÁPIDO: │
│ • Detener pipeline en primera falla │
│ • No desperdiciar recursos en builds condenados │
│ • Proporcionar feedback inmediato a desarrolladores │
│ │
│ REINTENTAR FALLAS TRANSITORIAS: │
│ • Timeouts de red: reintentar 2-3 veces │
│ • Fallas de servicios externos: reintentar con backoff │
│ • No reintentar fallas determinísticas │
│ │
│ DEGRADACIÓN GRACEFUL: │
│ • Checks no críticos pueden advertir vs bloquear │
│ • Builds de documentación no bloquean releases de código │
│ • Tests de performance pueden ser advisory │
└─────────────────────────────────────────────────────────────┘
Estrategias de Caché
CACHÉ EFECTIVO:
┌───────────────────┬─────────────────────┬───────────────────┐
│ TIPO DE CACHÉ │ BENEFICIO │ INVALIDACIÓN │
├───────────────────┼─────────────────────┼───────────────────┤
│ Dependencias │ Saltar npm/pip inst │ Cambio lockfile │
│ Artefactos build │ Builds incrementales│ Cambio de fuente │
│ Capas Docker │ Builds imagen rápido│ Cambio Dockerfile │
│ Fixtures de test │ Setup tests rápido │ Cambio fixtures │
└───────────────────┴─────────────────────┴───────────────────┘
MEJORES PRÁCTICAS DE CACHÉ:
• Usar claves content-addressable (hash de inputs)
• Establecer TTLs apropiados (1 semana para deps)
• Monitorear tasas de cache hit
• Limpiar cachés en fallas extrañas
Monitoreo y Observabilidad
Métricas del Pipeline
MÉTRICAS CLAVE DEL PIPELINE:
┌─────────────────────┬─────────────┬─────────────────────────┐
│ MÉTRICA │ OBJETIVO │ ACCIÓN SI NO SE CUMPLE │
├─────────────────────┼─────────────┼─────────────────────────┤
│ Tiempo de build │ < 15 min │ Optimizar etapas lentas │
│ Tasa de éxito │ > 90% │ Arreglar tests flaky │
│ Tiempo de cola │ < 5 min │ Agregar más runners │
│ Tiempo recuperación │ < 30 min │ Mejorar rollback │
│ Frecuencia deploy │ Diario+ │ Reducir tamaño batch │
└─────────────────────┴─────────────┴─────────────────────────┘
Alertas
ALERTAS DEL PIPELINE:
┌────────────────────────────┬────────────────────────────────┐
│ CONDICIÓN │ ALERTAR A │
├────────────────────────────┼────────────────────────────────┤
│ Branch main roto │ Canal equipo (alta prioridad) │
│ Tiempo build > 2x normal │ Líder DevOps │
│ Tests flaky aumentando │ Equipo de desarrollo │
│ Deploy a prod fallido │ On-call + canal de incidentes │
│ Security scan falla │ Equipo de seguridad │
└────────────────────────────┴────────────────────────────────┘
ESCALAMIENTO:
• Problema no resuelto en 30 min → Escalar a tech lead
• Branch main roto > 1 hora → Todos en deck
• Deploy prod fallido → Rollback inmediato + post-mortem
Seguridad en el Pipeline
Escaneo de Seguridad
ETAPAS DE SEGURIDAD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESCANEO DE DEPENDENCIAS: │
│ • Verificar CVEs conocidos en dependencias │
│ • Bloquear en vulnerabilidades críticas │
│ • Advertir en vulnerabilidades medias/bajas │
│ • Ejecutar en cada build │
│ │
│ ANÁLISIS ESTÁTICO (SAST): │
│ • Buscar patrones de código inseguro │
│ • Detectar inyección SQL, XSS, etc. │
│ • Integrar con herramientas como SonarQube │
│ │
│ DETECCIÓN DE SECRETOS: │
│ • Buscar API keys, passwords hardcodeados │
│ • Bloquear commits con secretos │
│ • Usar herramientas como git-secrets, truffleHog │
│ │
│ ESCANEO DE CONTENEDORES: │
│ • Escanear imágenes Docker por vulnerabilidades │
│ • Verificar configuraciones inseguras │
│ • Bloquear imágenes con issues críticos │
└─────────────────────────────────────────────────────────────┘
Integración con GitScrum
Visibilidad del Pipeline
GITSCRUM + PIPELINE CI/CD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ VISTA DE TAREA EN GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ [TASK-456] Implementar autenticación ││
│ │ ││
│ │ ESTADO PIPELINE: ││
│ │ ├── Lint: ✅ 32s ││
│ │ ├── Unit Tests: ✅ 2m 15s ││
│ │ ├── Build: ✅ 3m 42s ││
│ │ ├── Integration: ✅ 8m 20s ││
│ │ └── Deploy Staging: ✅ completado ││
│ │ ││
│ │ TOTAL: 14m 49s ││
│ │ [Ver logs completos →] ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BENEFICIOS: │
│ • Desarrolladores ven estado sin salir de GitScrum │
│ • PM sabe cuando feature está lista para testing │
│ • Historial de builds vinculado a tareas │
└─────────────────────────────────────────────────────────────┘