Introducción
El vocabulario de la integración continua y el criterio para elegir qué automatizar.
En un repositorio sin integración continua, la calidad descansa en una frase que nadie ha escrito: «antes de hacer push, lanza los tests». Funciona unas pocas semanas. Luego, un viernes por la noche, alguien sube una corrección de una línea sin ejecutarlos, porque una línea no rompe nada. El lunes, la rama principal está en rojo, tres personas ya se han basado en ella y se necesita media jornada para distinguir el commit culpable de los commits que simplemente se apoyaron en él. El coste real no es el test que faltó, sino el tiempo que transcurre entre el error y su descubrimiento.
La integración continua ataca precisamente ese retraso. Traslada la verificación del equipo del desarrollador a una máquina neutra que la ejecuta en cada push, sin excepciones, sin depender de la disciplina de nadie. Aporta tres cosas que ninguna convención de equipo ofrece: la reproducibilidad, porque el entorno se describe en un archivo versionado y no en un equipo de trabajo; la trazabilidad, porque cada ejecución deja un registro fechado y vinculado a un commit concreto; y la obligatoriedad, porque un resultado en rojo puede bloquear una fusión, algo que un recordatorio verbal nunca ha conseguido.
Comentarios
Los comentarios funcionan con GitHub Discussions
Inicia sesión con GitHub para participar en la discusión