¿Qué es la integración continua y cómo se configura?

La integración continua (CI) es el proceso de combinar cambios de código automáticamente y verificar que todo funcione sin errores cada vez que alguien actualiza el repositorio.

El problema que CI resuelve

Imagina que trabajas en el equipo de tecnología de Liverpool. Son cinco desarrolladores. Cada quien lleva tres días trabajando en su propia rama de Git. El viernes por la tarde, todos intentan fusionar su código al mismo tiempo. El sistema explota. Los errores se acumulan. Nadie sabe qué cambio rompió qué. El lanzamiento se retrasa un fin de semana entero, justo antes del Buen Fin.

Eso se llama "integration hell". Y CI existe exactamente para que eso no pase.

Con integración continua, cada vez que un desarrollador hace git push, el sistema verifica automáticamente que el código nuevo no rompa nada. Los errores aparecen en minutos, no en días.

El Sistema de Verificación Automática (SVA)

Piensa en CI como un inspector de calidad que nunca duerme. Cada vez que llega código nuevo, el inspector lo revisa con una lista de pasos fijos. Si algo falla, manda una alerta de inmediato. Si todo pasa, el código queda aprobado.

Ese proceso de pasos fijos se llama pipeline de CI. Tiene tres etapas básicas:

1. Construir (Build): Convierte el código fuente en algo ejecutable.
2. Probar (Test): Ejecuta pruebas automáticas para detectar errores.
3. Reportar (Report): Muestra si todo pasó o dónde falló.

Este sistema no reemplaza a los desarrolladores. Los libera de verificar manualmente. Ellos se enfocan en crear; el pipeline se encarga de vigilar.

¿Qué es GitHub Actions?

GitHub Actions es la herramienta gratuita de GitHub para crear pipelines de CI directamente dentro de tu repositorio. No necesitas instalar nada extra. Todo vive en un archivo de configuración dentro de tu proyecto.

Ese archivo se llama workflow y se guarda en esta ruta:

.github/workflows/ci.yml

El formato del archivo es YAML. Es fácil de leer: usa indentación para organizar los pasos, como una lista de instrucciones.

Tu primer pipeline de CI paso a paso

Vamos a construir un pipeline real. Supón que tienes un proyecto Python que calcula descuentos para una tienda en línea, similar a lo que usa Mercado Libre en sus promociones.

Paso 1: Estructura del proyecto

Tu proyecto tiene estos archivos:

tienda/
  descuentos.py
  test_descuentos.py
.github/
  workflows/
    ci.yml

Paso 2: El código principal

Archivo descuentos.py:

def calcular_descuento(precio, porcentaje):
    descuento = precio * (porcentaje / 100)
    precio_final = precio - descuento
    return precio_final

Paso 3: Las pruebas automáticas

Archivo test_descuentos.py:

from descuentos import calcular_descuento

def test_descuento_basico():
    resultado = calcular_descuento(1000, 10)
    assert resultado == 900, "El descuento del 10% no calculó bien"

def test_descuento_buen_fin():
    resultado = calcular_descuento(5000, 20)
    assert resultado == 4000, "El descuento del Buen Fin falló"

def test_sin_descuento():
    resultado = calcular_descuento(2500, 0)
    assert resultado == 2500, "Sin descuento el precio debe quedar igual"

Estas pruebas verifican que la función calcula bien. Si alguien modifica calcular_descuento y rompe la lógica, las pruebas lo detectan automáticamente.

Paso 4: El archivo de workflow

Archivo .github/workflows/ci.yml:

name: CI Pipeline Tienda

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

jobs:
  verificar:
    runs-on: ubuntu-latest

    steps:
      - name: Descargar código
        uses: actions/checkout@v3

      - name: Instalar Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      - name: Instalar dependencias
        run: pip install pytest

      - name: Ejecutar pruebas
        run: pytest test_descuentos.py -v

Analicemos cada parte:

• on: push: El pipeline arranca cada vez que alguien hace push a main o develop.
• on: pull_request: También corre cuando alguien abre un Pull Request hacia main.
• runs-on: ubuntu-latest: Las pruebas corren en un servidor Linux limpio.
• actions/checkout@v3: Descarga tu código al servidor.
• pytest test_descuentos.py -v: Ejecuta las pruebas con detalle.

Paso 5: Ver los resultados

Cuando haces git push, ve a tu repositorio en GitHub. Haz clic en la pestaña Actions. Verás tu workflow corriendo en tiempo real. Si todo pasa, aparece un ícono verde. Si algo falla, aparece un ícono rojo con el detalle exacto del error.

Ejemplo real: error detectado automáticamente

Supón que un desarrollador del equipo modifica calcular_descuento por accidente:

def calcular_descuento(precio, porcentaje):
    descuento = precio * (porcentaje / 10)  # Error: dividió entre 10, no entre 100
    precio_final = precio - descuento
    return precio_final

Hace git push. El pipeline arranca. La prueba test_descuento_basico falla porque calcular_descuento(1000, 10) devuelve 0 en vez de 900. GitHub Actions muestra el error en menos de dos minutos. El desarrollador lo corrige antes de que ese código llegue a producción.

Sin CI, ese error podría llegar a los clientes. En una tienda como la de Bimbo con distribución en línea, un error en precios puede costar miles de pesos en devoluciones o ventas a precios incorrectos.

¿Con qué frecuencia debe correr el pipeline?

La respuesta es simple: siempre. Cada push, cada Pull Request. No hay excepciones.

Algunos equipos desactivan el pipeline "solo esta vez" porque están apurados. Eso es exactamente cuando más lo necesitan. Los errores no avisan cuándo llegan.

Un equipo maduro en FEMSA Tech, por ejemplo, tiene reglas claras: ningún código entra a main si el pipeline no está en verde. El pipeline es el guardián de la rama principal.

Errores comunes al configurar CI

Error 1: No guardar el archivo en la ruta correcta. El archivo debe estar en .github/workflows/. Si lo pones en otra carpeta, GitHub Actions no lo detecta. El pipeline nunca corre y no aparece ningún error visible.

Error 2: Olvidar instalar las dependencias en el pipeline. Tu máquina local ya tiene todo instalado. El servidor del pipeline está limpio. Si tu código usa pandas o requests, debes instalarlo explícitamente en el archivo YAML con pip install.

Error 3: Escribir pruebas que siempre pasan. Algunos desarrolladores escriben pruebas vacías para cumplir el requisito. Una prueba que no verifica nada real no protege a nadie. Cada prueba debe tener al menos un assert con un valor concreto.

Error 4: Solo probar en main. Si el pipeline solo corre en main, los errores llegan tarde. Configura el pipeline para que también corra en develop y en cada Pull Request. Detecta los errores antes de que entren a la rama principal.

Error 5: Ignorar los fallos del pipeline. Si el pipeline falla y el equipo lo ignora porque "siempre pasa", deja de ser útil. Un pipeline roto que nadie atiende es peor que no tener pipeline. Designa a alguien responsable de mantenerlo en verde.

¿Qué pasa después del CI?

Cuando el pipeline pasa todas las pruebas, el código está listo para la siguiente etapa: la entrega continua (CD). Eso lo veremos en lecciones posteriores. Por ahora, lo importante es que CI te da certeza: si el pipeline está verde, el código funciona como se espera.

Cada vez que configuras un pipeline, estás construyendo confianza en tu equipo. Los errores se vuelven predecibles. Los lanzamientos dejan de ser eventos de pánico.

Un pipeline de CI bien configurado convierte el caos del viernes en una rutina confiable de cualquier día de la semana.