El primer flujo de integración continua: qué poner y qué no
Un flujo que tarda veinte minutos deja de usarse. La primera decisión de diseño no es qué comprobar, sino cuánto puede tardar.
Rápido antes que completo
La decisión de diseño que más determina si un flujo de integración se usa no es qué comprueba, sino cuánto tarda. Un flujo que devuelve resultado en dos minutos se consulta; uno que tarda veinte se ignora, y la gente aprende a fusionar sin esperarlo.
Conviene fijar un tiempo objetivo desde el principio y defenderlo: cada comprobación nueva compite contra él.
Las tres etapas que compensan desde el primer día
- Construir. Que el proyecto compile o se empaquete. Detecta el error más tonto y más frecuente.
- Pruebas rápidas. Un subconjunto que se ejecute en segundos y cubra lo esencial.
- Comprobaciones estáticas. Formato, errores evidentes y —muy importante— que no se hayan colado credenciales.
Todo lo demás —pruebas lentas, análisis profundos, construcción de imágenes— puede ejecutarse aparte, en otro momento, sin bloquear a quien está esperando.
Qué no poner en el flujo rápido
| Comprobación | ¿En el flujo rápido? | Alternativa |
|---|---|---|
| Compilación | Sí | — |
| Pruebas unitarias | Sí, las rápidas | El resto, en paralelo |
| Pruebas de extremo a extremo | No | Ejecución nocturna o previa a publicar |
| Análisis de seguridad profundo | No | Programado, con revisión |
| Construcción de imagen | Sólo si se despliega | Al fusionar |
| Despliegue a producción | Nunca automático sin decisión | Etapa manual |
Empezar con lo que ya se hace a mano
El primer flujo no debería introducir prácticas nuevas. Debería automatizar exactamente lo que alguien ya hace manualmente antes de publicar. Así el equipo reconoce el resultado y confía en él; añadir etapas que nadie pidió produce fallos que nadie sabe interpretar.
