Semestre 02, 2026
Si una actividad resulta costosa y dolorosa, hay que hacerla más seguido hasta volverla trivial.
Práctica en la que cada miembro del equipo integra su trabajo a un repositorio compartido al menos una vez al día, y cada integración se verifica con una compilación y una batería de pruebas automáticas.
Cuando cada desarrollador trabaja aislado durante semanas, el código divergente crece sin que nadie lo note.
Una funcionalidad de tres semanas no cabe en una rama de un día, pero mantenerla aislada tres semanas reintroduce el problema que la práctica quiere eliminar.
La pirámide de pruebas es una guía de proporción, con la mayoría en la base y muy pocas en la punta.
flowchart LR
A[Commit al main branch] --> B[El servidor de CI detecta el cambio]
B --> C[Compilar]
C --> D[Pruebas]
D --> E[Análisis estático y dependencias]
E --> F[Publicar artefacto]
F --> G{Build en verde}
G -->|Sí| H[Main branch listo para desplegar]
G -->|No| I[Notificar y corregir de inmediato]
| Herramienta | Cuándo conviene |
|---|---|
| GitHub Actions | El código ya está en GitHub, es la opción por defecto |
| GitLab CI/CD | Se quiere repositorio, pipelines y seguridad en un solo producto |
| CircleCI | El tiempo de build es una restricción medible |
| Jenkins | Hay una restricción que lo obliga, como entornos aislados o hardware propio |
Jenkins es el más flexible y también el que más mantenimiento exige, así que solo se justifica cuando existe un equipo que pueda sostenerlo.
Se requiere un pipeline que, en cada push al main branch y en cada pull request, instale las dependencias con versiones fijas, ejecute el análisis estático y corra la batería de pruebas de un proyecto en Node.
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
verificar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- run: npm ci
- run: npm run lint
- run: npm test
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
verificar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- run: npm ci
- run: npm run lint
- run: npm test
El nombre con el que el pipeline aparece en la pestaña de Actions y en el estado de cada commit. El archivo vive en .github/workflows y está versionado junto al código, así que la definición del pipeline evoluciona con el proyecto.
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
verificar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- run: npm ci
- run: npm run lint
- run: npm test
Los disparadores del pipeline. Corre en cada push al main branch y en cada pull request dirigido al main branch, que son los dos momentos donde importa saber si el sistema sigue funcionando.
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
verificar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- run: npm ci
- run: npm run lint
- run: npm test
Un job es una unidad de trabajo y runs-on declara la máquina donde se ejecuta. GitHub provee una máquina limpia en cada corrida, que es lo que convierte al pipeline en un entorno de referencia y no en la laptop de alguien.
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
verificar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- run: npm ci
- run: npm run lint
- run: npm test
Los pasos con uses invocan acciones reutilizables. La primera descarga el código del commit que disparó el pipeline y la segunda instala la versión exacta del lenguaje, fijada para que el build sea reproducible.
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
verificar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- run: npm ci
- run: npm run lint
- run: npm test
Los pasos con run ejecutan comandos. Aquí está el build auto-verificable, con dependencias en versiones fijas, análisis estático y batería de pruebas. Si cualquier paso termina con código distinto de cero, el job falla y el commit queda marcado en rojo.
La integración continua no es una etapa del ciclo de vida, es una práctica que atraviesa todas sus etapas.
flowchart TD
A[Rama corta desde main] --> B[Commit local y pruebas en local]
B --> C[Traer main y resolver conflictos]
C --> D[Pull request hacia main]
D --> E[El pipeline verifica la combinación real]
E --> F[Revisión de código]
F --> G[Merge a main el mismo día]
G --> A
Las políticas del repositorio impiden que la disciplina dependa de la buena memoria del equipo.
Medir el pipeline es la única forma de saber si la práctica funciona o solo existe en el papel.
| Métrica | Qué indica |
|---|---|
| Frecuencia de integración | Cuántas veces al día llega trabajo al main branch |
| Duración del build | Techo recomendado de diez minutos |
| Tasa de builds exitosos | Porcentaje de commits que producen build en verde |
| Tiempo de reparación | Cuánto tarda el main branch en volver a verde |
| Frecuencia de despliegue | Cuántas veces llega software a producción |
| Tiempo de entrega del cambio | Del commit hasta que corre en producción |
La mayoría de los fracasos no vienen de la herramienta, vienen de la disciplina que la rodea.
No existe entrega continua sin integración continua, ni despliegue continuo sin entrega continua.
La evidencia de DORA asocia la práctica con mayor frecuencia de despliegue, sistemas más estables y entregas más predecibles.