La integración continua requiere la integración diaria de código en el tronco (trunk) con pruebas automatizadas. Aprenda las mejores prácticas de CI, las estrategias de prueba y los flujos de trabajo en equipo que mejoran la calidad del software y la velocidad de entrega.

Definición#

La Integración Continua (CI) es la actividad de cada desarrollador que integra su trabajo al tronco del control de versiones al menos una vez al día y verifica que el trabajo sea, según nuestro conocimiento, liberable.

La CI no se trata solo de herramientas: se trata fundamentalmente del flujo de trabajo del equipo y de los acuerdos de trabajo.

Las actividades mínimas requeridas para la IC#

  1. Desarrollo basado en el tronco : todo el trabajo se integra al tronco
  2. El trabajo se integra al tronco como mínimo diariamente (cada desarrollador, todos los días)
  3. El trabajo ha automatizado las pruebas antes de la fusión con el tronco
  4. El trabajo se prueba con otro trabajo automáticamente al fusionarlo
  5. Todo el trabajo de las funciones se detiene cuando la compilación está en rojo
  6. El nuevo trabajo no interrumpe el trabajo entregado

Por qué esto es importante#

Sin CI, la experiencia de los equipos#

  • El infierno de la integración : semanas o meses de dolorosos conflictos de fusión
  • Detección tardía de defectos : errores que se encuentran después de que son costosos de solucionar
  • Colaboración reducida : los desarrolladores trabajan de forma aislada y pierden contexto.
  • Miedo a al despliegue : grandes lotes de cambios no probados crean riesgo
  • Entrega más lenta : tiempo perdido en conflictos de fusión y reelaboración
  • Erosión de la calidad : sin una retroalimentación rápida, la deuda técnica se acumula

Con CI, los equipos logran#

  • Retroalimentación rápida : sepa en minutos si los cambios rompieron algo
  • Cambios más pequeños : la integración diaria obliga a una mejor distribución del trabajo
  • Mejor colaboración : el equipo comparte la propiedad del código base
  • Menor riesgo : los cambios pequeños y probados son más fáciles de diagnosticar y solucionar.
  • Entrega más rápida : Sin retrasos en la integración que bloqueen la implementación
  • Mayor calidad : las pruebas continuas detectan los problemas de forma temprana

Acuerdos de trabajo en equipo#

Si bien la IC depende de las herramientas, el flujo de trabajo del equipo y el acuerdo de trabajo son más importantes:

  1. Definir trabajo comprobable : el trabajo incluye criterios de aceptación comprobables que impulsan los esfuerzos de prueba.
  2. Las pruebas acompañan a las confirmaciones : ningún trabajo se compromete (commit) con el control de versiones sin las pruebas requeridas
  3. Progreso incremental : el trabajo comprometido puede no estar “completo en sus funciones”, pero no debe interrumpir el trabajo existente.
  4. Flujo de trabajo basado en el tronco : todo el trabajo comienza desde el tronco y se integra al tronco al menos una vez al día
  5. Detener la línea : si CI detecta un error, el equipo detiene el trabajo de la función y colabora para corregir la compilación de inmediato.

La práctica de detener la línea es fundamental para mantener un tronco siempre liberable. Para obtener instrucciones detalladas sobre la implementación de esta disciplina, consulte " Todo el trabajo de las funciones se detiene cuando la compilación está en rojo" .

Implementaciones de ejemplo#

Antipatrón: Flujo de trabajo de feature branch sin CI# 

Developer A: feature-branch-1 (3 weeks of work)
Developer B: feature-branch-2 (2 weeks of work)
Developer C: feature-branch-3 (4 weeks of work)

Semana 4: Conflictos de fusión, problemas de integración, pruebas fallidas
Semana 5: Seguimos solucionando los problemas de integración
Semana 6: Finalmente estabilizado, pero perdimos 2 semanas en la integración

Problemas#

  • Las ramas de larga duración acumulan conflictos de fusión
  • Problemas de integración descubiertos tarde
  • No hay comentarios anticipados sobre la compatibilidad
  • Grandes lotes de cambios no probados
  • Equipo bloqueado mientras resuelve conflictos

Buen patrón: Integración continua con el tronco# 

# .github/workflows/ci.yml
name: Continuous Integration

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install dependencies
        run: npm ci

      - name: Run unit tests
        run: npm test

      - name: Run integration tests
        run: npm run test:integration

      - name: Code quality checks
        run: npm run lint

      - name: Security scan
        run: npm audit

      - name: Build application
        run: npm run build

  notify-on-failure:
    needs: test
    if: failure()
    runs-on: ubuntu-latest
    steps:
      - name: Notify team
        run: |
          echo "Build failed - stop feature work and fix!"
          # Send Slack/email notification

Beneficios#

  • Cambios probados en minutos
  • El equipo recibe retroalimentación inmediata
  • Los pequeños cambios son fáciles de depurar
  • La integración nunca es una sorpresa
  • Calidad mantenida continuamente

Prácticas de codificación evolutiva#

Para integrar código a diario mientras se crean grandes funcionalidades, utilice patrones como branch by abstraction, feature flags y connect-last. Estas técnicas le permiten dividir los cambios grandes en confirmaciones pequeñas y seguras que se integran en el tronco a diario sin interrumpir la funcionalidad existente

Para obtener orientación detallada y ejemplos de código, consulte Prácticas de codificación evolutiva.

Pruebas en CI#

Una estrategia de pruebas integral equilibra la retroalimentación rápida con una validación exhaustiva. Ejecute diferentes tipos de pruebas en diferentes etapas del proceso de desarrollo:

  • Pruebas previas a la fusión (<10 minutos): pruebas unitarias, análisis de estilo, análisis de seguridad estáticos, auditorías de dependencias
  • Pruebas posteriores a la fusión (<30 minutos): todas las pruebas previas a la fusión más pruebas de integración, pruebas funcionales, pruebas de rendimiento (validar el tiempo de respuesta y los requisitos de rendimiento) y pruebas de seguridad dinámicas
  • Pruebas de implementación : las pruebas de humo y de extremo a extremo pertenecen al proceso de despliegue , no a la CI.

Para obtener orientación detallada sobre la estrategia de pruebas, la pirámide de pruebas, las pruebas deterministas y la calidad de las pruebas, consulte Estrategias de pruebas.

Qué se mejora#

Trabajo en equipo#

La integración continua requiere un sólido trabajo en equipo para funcionar correctamente. Mejoras clave:

  • Flujo de trabajo de extracción : el equipo elige el próximo trabajo importante en lugar de trabajar a partir de asignaciones
  • Cadencia de revisión de código : Las revisiones rápidas (<4 horas) mantienen el flujo de trabajo
  • Programación en pareja : la colaboración en tiempo real elimina los retrasos en las revisiones
  • Propiedad compartida : todos mantienen el código base juntos
  • Los objetivos del equipo se anteponen a las tareas individuales : el enfoque cambia de “mi trabajo” a “nuestro progreso”.

Antipatrón : El flujo de trabajo “push” donde se asigna el trabajo crea silos y demoras.

Desglose del trabajo#

La IC fuerza una mejor descomposición del trabajo:

  • Definición de listo : Cada historia tiene criterios de aceptación comprobables antes de que comience el trabajo
  • Lotes pequeños : si el equipo puede completar el trabajo en menos de 2 días, está lo suficientemente refinado.
  • Segmentación vertical : cada cambio proporciona una porción delgada y probada de funcionalidad
  • Entrega incremental : funciones desarrolladas de forma incremental, cada paso integrado diariamente

Consulte el desglose del trabajo para obtener orientación detallada.

Pruebas#

La integración continua requiere un cambio en el enfoque de las pruebas:

De : Escribir pruebas después de que el código esté “completo” a : Escribir pruebas antes/durante la codificación (TDD/BDD)

De : Probar detalles de implementación a : Probar comportamiento y resultados

De : Pruebas manuales antes de la implementación a : Pruebas automatizadas en cada confirmación

De : Fase de control de calidad independiente Hasta : Calidad integrada en el desarrollo

Los equipos de CI crean un conjunto de pruebas integral con el objetivo de detectar problemas lo más cerca posible de su creación. Consulte Desarrollo basado en el comportamiento .

Desafíos comunes#

¿Cuáles son los principales problemas a superar?#

  1. Trabajo en equipo deficiente : generalmente impulsado por la asignación de trabajo en lugar de utilizar un sistema de atracción
  2. Falta de criterios de aceptación comprobables : esto se agrava por las asignaciones individuales en lugar de los objetivos de equipo. BDD proporciona pruebas funcionales declarativas que todos comprenden.
  3. Falta de conocimiento de codificación evolutiva : “¡No puedo confirmar hasta que la función esté completa!”. Use branch by abstraction, feature flags o planificar cambios para que el último cambio integre la función.

“¿Cómo puedo completar una función grande en menos de un día?”#

Probablemente no lo completes en un día, pero integras el progreso a diario. Consulta [Prácticas de Codificación Evolutiva](branch by abstraction, feature flags) para ver patrones detallados y ejemplos de código.

“¿Qué nivel de cobertura de código se necesita antes de poder realizar CI?”#

No es necesario realizar pruebas en el código existente para iniciar la integración continua. Es necesario probar el código nuevo sin excepciones .

Punto de partida : “No bajaremos del nivel actual de cobertura de código”.

“¿Qué porcentaje de cobertura de código deberíamos tener?”#

“Tengo confianza.” ¿Está seguro de haber cubierto suficientes casos positivos y negativos?

Mejor pregunta : “¿Confiamos en nuestras pruebas?” El porcentaje de cobertura de las pruebas no indica la calidad de las pruebas.

“¿Deberíamos establecer un estándar de cobertura de código para todos los equipos?”#

No. Los mandatos de cobertura de código incentivan pruebas sin sentido que ocultan el hecho de que el código no se prueba.

Es mejor no tener pruebas que tener pruebas en las que no confíes.

En su lugar: Céntrese en la calidad de las pruebas, la cobertura del comportamiento y la disciplina del equipo. Consulte Cobertura del Código para obtener instrucciones detalladas.

Supervisión del estado de la integración continua#

Realice un seguimiento de estas métricas clave para comprender la eficacia de la IC e impulsar la mejora:

  • Compromisos por día por desarrollador : ≥ 1 (promedio del equipo): indica disciplina de integración
  • Tiempo del ciclo de desarrollo : <2 días en promedio—muestra un desglose efectivo del trabajo
  • Tasa de éxito de compilación : > 95 % (refleja la calidad de las pruebas previas a la fusión)
  • Tiempo para reparar una compilación defectuosa : <1 hora (demuestra compromiso de detener la línea)
  • Tasa de defectos : estable o decreciente: garantiza que la velocidad no sacrifique la calidad

Haga visible el estado del pipeline para todos mediante paneles, notificaciones y radiadores de compilación. La visibilidad impulsa una respuesta más rápida, la responsabilidad compartida y la mejora continua.

Para obtener orientación detallada sobre métricas, paneles y uso de datos para mejoras, consulte Métricas de visibilidad y estado de la canalización .

Recursos adicionales#

Nota: Este post es una traduccion de Evolutionary Coding Practices bajo la licencia: CC BY 4.0.