Mejores Prácticas de Continuous Integration

Continuous Integration significa integrar código frecuentemente y validar cada integración automáticamente. Un buen CI detecta bugs temprano, habilita refactoring con confianza y mantiene el branch main siempre listo para release. Esta guía cubre implementación práctica de CI.

Etapas del Pipeline CI

Estructura del Pipeline

Etapas Esenciales

ETAPAS DEL PIPELINE CI
══════════════════════

ETAPA 1: LINT & FORMAT
─────────────────────────────────────
Propósito: Estilo de código consistente
Herramientas: ESLint, Prettier, Black, etc.
Tiempo: <1 minuto

Verificaciones:
├── Formateo de código
├── Reglas de estilo
├── Orden de imports
├── Sin variables sin usar
└── Detectar issues antes de review

ETAPA 2: UNIT TESTS
─────────────────────────────────────
Propósito: Verificación de lógica
Herramientas: Jest, PyTest, JUnit, etc.
Tiempo: <5 minutos

Ejecutar:
├── Todos los unit tests
├── Tests rápidos, aislados
├── Sin dependencias externas
├── Áreas de alta cobertura
└── Feedback rápido

ETAPA 3: BUILD
─────────────────────────────────────
Propósito: Verificar compilación
Herramientas: Webpack, tsc, cargo, etc.
Tiempo: <3 minutos

Verificar:
├── Código compila
├── Dependencias resuelven
├── Assets generados
├── Artefactos de build creados
└── Puede producir output

ETAPA 4: INTEGRATION TESTS
─────────────────────────────────────
Propósito: Interacción de componentes
Herramientas: Frameworks de test + BD/servicios de test
Tiempo: <10 minutos

Testear:
├── Endpoints de API
├── Operaciones de base de datos
├── Interacciones de servicios
├── Flujos clave
└── Escenarios realistas

ETAPA 5: SECURITY SCAN
─────────────────────────────────────
Propósito: Encontrar vulnerabilidades
Herramientas: Snyk, OWASP, npm audit, etc.
Tiempo: <5 minutos

Escanear:
├── Vulnerabilidades de dependencias
├── Issues de seguridad en código
├── Detección de secrets
├── Cumplimiento de licencias
└── Gates de seguridad

Configuración del Pipeline

EJEMPLO DE CONFIGURACIÓN CI
═══════════════════════════

EJEMPLO GITHUB ACTIONS:
─────────────────────────────────────
name: CI
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npm test

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npm run build

  integration:
    runs-on: ubuntu-latest
    needs: [lint, test, build]
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npm run test:integration

EJECUCIÓN PARALELA:
─────────────────────────────────────
├── Lint, Test, Build corren en paralelo
├── Integration corre después que todos pasan
├── Pipeline general más rápido
├── Falla temprana, feedback temprano
└── Optimizar para velocidad

Feedback Rápido

La Velocidad Importa

OPTIMIZACIÓN DE VELOCIDAD CI
════════════════════════════

POR QUÉ LA VELOCIDAD IMPORTA:
─────────────────────────────────────
CI lento:
├── Desarrolladores esperan
├── Cambian a otro trabajo
├── Costo de context switch
├── Acumulan cambios
├── Encuentran issues tarde
└── Frustración

CI rápido:
├── Feedback inmediato
├── Arreglar mientras contexto fresco
├── Commits más frecuentes
├── Detectar issues temprano
├── Felicidad del desarrollador
└── Mayor calidad

OBJETIVOS DE VELOCIDAD:
─────────────────────────────────────
├── Lint: <1 minuto
├── Unit tests: <5 minutos
├── Pipeline completo: <10 minutos
├── Máximo absoluto: 15 minutos
└── Más rápido es mejor

ESTRATEGIAS DE OPTIMIZACIÓN:
─────────────────────────────────────
Caching:
├── Cachear dependencias
├── Cachear artefactos de build
├── Cachear fixtures de test
├── Reusar lo que no cambia
└── Speedup significativo

Paralelización:
├── Correr etapas independientes en paralelo
├── Dividir suites de test
├── Múltiples runners
├── Reducir tiempo de reloj
└── Usar recursos disponibles

Optimización de tests:
├── Tests unitarios rápidos (mayoría)
├── Menos tests de integración
├── Tests más lentos al final
├── Saltear áreas sin cambios
└── Pirámide de testing

Manteniendo Verde

Siempre Listo para Release

MANTENIENDO CI VERDE
════════════════════

REGLA: ARREGLAR BUILDS ROTOS INMEDIATAMENTE
─────────────────────────────────────
Cuando CI falla:
├── Parar otro trabajo
├── Arreglar inmediatamente
├── O revertir el cambio
├── Prioridad máxima del equipo
└── Build roto = equipo bloqueado

RESPONSABILIDAD:
─────────────────────────────────────
Quien lo rompió lo arregla:
├── Tu commit, tu arreglo
├── Respuesta rápida
├── No dejar para después
├── No ignorar
└── Ownership

EVITAR BUILDS ROTOS:
─────────────────────────────────────
Prevención:
├── Correr tests localmente primero
├── Commits pequeños y frecuentes
├── Code review exhaustivo
├── Pre-commit hooks
└── Detectar antes de push

Pre-commit:
├── Check de lint
├── Check de formato
├── Unit tests rápidos
├── Detectar issues obvios
└── Feedback más rápido

VERDE = LISTO PARA RELEASE:
─────────────────────────────────────
Branch main siempre debe ser:
├── Buildeable
├── Tests pasando
├── Deployable
├── Listo para producción
└── Enviar en cualquier momento

Frecuencia de Integración

Merge Frecuente

INTEGRACIÓN FRECUENTE
═════════════════════

MERGE DIARIO (MÍNIMO):
─────────────────────────────────────
Mejor práctica:
├── Múltiples merges por día
├── Cambios pequeños cada vez
├── Nunca más de 1 día sin merge
├── Branches largos = problemas de integración
└── Continuo significa continuo

CAMBIOS PEQUEÑOS:
─────────────────────────────────────
Beneficios de pequeño:
├── Más fácil de revisar
├── Menos probable que conflicte
├── Problemas aislados
├── Fácil de revertir
├── Feedback más rápido
└── Menor riesgo

FEATURE FLAGS:
─────────────────────────────────────
Merge features incompletas:
├── Código deployed pero inactivo
├── Flag controla visibilidad
├── Integrar continuamente
├── Habilitar cuando listo
└── Desacoplar deploy de release

Ejemplo:
├── Merge código auth (flag off)
├── Continuar desarrollo
├── Seguir integrando
├── Habilitar flag cuando completo
├── Usuarios nunca ven incompleto

Quality Gates

Verificaciones Requeridas

QUALITY GATES CI
════════════════

REQUERIDO PARA MERGE:
─────────────────────────────────────
☐ Todos los tests pasando
☐ Lint limpio
☐ Build exitoso
☐ Umbral de cobertura cumplido
☐ Scan de seguridad limpio
☐ Code review aprobado
└── Todo debe pasar para merge

PROTECCIÓN DE BRANCH:
─────────────────────────────────────
Configuración GitHub:
├── Requerir status checks para pasar
├── Requerir reviews antes de merge
├── Requerir branch actualizado
├── Bloquear force pushes
├── Aplicar a administradores
└── Main protegido

UMBRALES:
─────────────────────────────────────
Ejemplos de umbrales:
├── Cobertura de código: >80%
├── Sin vulnerabilidades críticas
├── Sin vulnerabilidades altas
├── Sin errores de lint
├── Sin warnings de TypeScript
└── Calidad asegurada

Mejores Prácticas

Para Implementación CI

CHECKLIST DE CI:
════════════════

CONFIGURACIÓN:
─────────────────────────────────────
☐ Pipeline definido como código
☐ Corre en cada push y PR
☐ Etapas paralelas donde posible
☐ Caching configurado
☐ Notificaciones configuradas
└── Infraestructura lista

TESTS:
─────────────────────────────────────
☐ Tests unitarios completos
☐ Tests de integración para flujos clave
☐ Tests rápidos y confiables
☐ Sin tests flaky
☐ Cobertura medida
└── Suite de tests sólida

CULTURA:
─────────────────────────────────────
☐ Builds rotos se arreglan inmediatamente
☐ Commits pequeños y frecuentes
☐ Code review antes de merge
☐ Main siempre verde
☐ Mejora continua del pipeline
└── Equipo comprometido

Anti-Patrones

ERRORES DE CI:
✗ Pipeline lento que nadie espera
✗ Tests flaky que se ignoran
✗ Builds rotos ignorados por días
✗ Sin pre-commit hooks locales
✗ Branches de larga duración
✗ Merges grandes y arriesgados
✗ Sin protección de branch

Soluciones Relacionadas

• Estrategias de continuous deployment
• Prácticas de continuous delivery
• Estrategias de testing automatizado