Continuous Integration (CI)

La integración continua (CI) consiste en incorporar con frecuencia, al menos a diario, los cambios de cada desarrollador a una rama principal compartida, y compilar y probar automáticamente cada cambio para que los problemas de integración salgan a la luz en cuestión de minutos, en vez de al publicar una versión. Grady Booch propuso el término en 1991, Kent Beck lo convirtió en una práctica fundamental de la Programación Extrema a finales de la década de 1990, y el artículo de Martin Fowler Integración continua describe el flujo de trabajo que la mayoría de los equipos sigue utilizando. En aprendizaje automático (ML), la CI también comprueba los datos, el código de entrenamiento y el comportamiento del modelo, porque un cambio puede hacer que todas las pruebas unitarias sigan pasando mientras reduce la precisión del modelo.

Cómo funciona un flujo de CI#

Cuando un desarrollador sube una rama o abre una solicitud de cambios, un servicio de CI como GitHub Actions, GitLab CI/CD o Jenkins inicia un entorno de ejecución limpio, obtiene el código, instala las dependencias y ejecuta una secuencia de tareas: linters y comprobadores de tipos, pruebas unitarias, pruebas de integración y compilaciones de paquetes o imágenes de contenedor. Cada tarea comunica su estado a la solicitud de cambios, y las reglas de protección de ramas pueden bloquear la fusión hasta que se superen todas las comprobaciones obligatorias. Los flujos suelen repetir las mismas pruebas en una matriz de sistemas operativos y versiones de Python, y vuelven a ejecutar la batería completa en la rama principal tras cada fusión. La velocidad forma parte de esta práctica: la Programación Extrema de Beck fijó un objetivo de diez minutos para compilar todo el sistema y ejecutar cada prueba, porque las compilaciones más lentas se ejecutan con menos frecuencia.

CI para aprendizaje automático#

Los proyectos de ML añaden sus propias comprobaciones. Las pruebas de datos confirman que los nuevos datos de entrenamiento cumplen el esquema previsto, que todos los archivos de etiquetas se pueden analizar y que ninguna imagen aparece tanto en la partición de entrenamiento como en la de validación, lo que provocaría fuga de datos. Una prueba de humo entrena durante una época con un conjunto de datos diminuto para detectar en minutos errores de forma y fallos. Las pruebas que comparan salidas del modelo fijan semillas aleatorias y admiten pequeñas tolerancias numéricas, ya que los kernels de GPU y el orden de carga de datos pueden alterar los resultados de coma flotante entre ejecuciones. Una puerta de calidad puntúa el modelo con un conjunto de validación fijo y falla la compilación si una métrica como la precisión media promedio (mAP) cae por debajo de un mínimo; las pruebas de exportación comprueban que las versiones del modelo en ONNX o TensorRT sigan cargándose y obteniendo puntuaciones similares a las del original. El entrenamiento completo es lento y los entornos de ejecución con GPU son caros, así que los equipos suelen ejecutar comprobaciones rápidas en cada solicitud de cambios y reservan el reentrenamiento completo y la implementación de modelos para ejecuciones programadas o en la rama principal; herramientas de versionado como DVC permiten que cada trabajo obtenga la versión exacta del conjunto de datos que necesita.

El modo de benchmark de Ultralytics YOLO funciona como una puerta de calidad: cuando verbose se establece en un valor decimal como 0.216, genera un error si falla una exportación o si el mAP_50-95 de cualquier formato exportado no supera ese mínimo, y la CI del propio repositorio de Ultralytics lo utiliza para probar las exportaciones de YOLO26 en entornos Linux, macOS y ARM. Un flujo de trabajo mínimo de GitHub Actions combina las pruebas unitarias con esa puerta:

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v6
        with:
          python-version: "3.13"
      - run: pip install ultralytics pytest
      - run: pytest tests/
      # Fail if the ONNX export breaks or its mAP50-95 is not above the 0.216 floor
      - run: yolo benchmark model=yolo26n.pt format=onnx imgsz=160 verbose=0.216

Cada solicitud de cambios y cada envío a main ejecutan el trabajo en un entorno de Ubuntu nuevo. Si falla una prueba unitaria o un modelo ONNX obtiene en el pequeño conjunto de datos COCO8 una puntuación igual o inferior al mínimo, la comprobación falla antes de que se pueda fusionar el cambio.

CI frente a CD, MLOps y entrenamiento continuo#

• Entrega continua (CD): Mantiene listos para su publicación los artefactos que superan la CI y, a menudo, los implementa automáticamente en un entorno de preproducción. La implementación continua va un paso más allá y distribuye en producción cada cambio que supera las pruebas.
• MLOps: Disciplina más amplia que combina CI y CD con el versionado de datos, la implementación de modelos, la supervisión y el reentrenamiento a lo largo del ciclo de vida del ML.
• Entrenamiento continuo (CT): Reentrena y vuelve a implementar un modelo automáticamente cuando llegan datos nuevos o la supervisión detecta una deriva. Los niveles de madurez de MLOps de Google sitúan el reentrenamiento automatizado en el nivel 1 y la CI/CD automatizada del propio flujo de entrenamiento en el nivel 2.