Tu pipeline de CI tarda 25 minutos: por dónde empezar

Cuando la CI tarda 25 minutos, la gente deja de esperarla. Fusiona antes de que acabe, abre tres ramas en paralelo y pierde la relación entre un cambio y el test que rompe. El coste real no es el tiempo de máquina, es el cambio de comportamiento.

1. Cachear dependencias

Si cada ejecución descarga e instala todo desde cero, ahí hay entre tres y ocho minutos regalados. Casi todas las plataformas de CI cachean el directorio de dependencias con una clave basada en el fichero de *lock*. Es la mejora con más retorno por hora invertida.

2. Paralelizar lo que no depende entre sí

Lint, type-check y tests unitarios no se necesitan mutuamente: pueden correr a la vez en *jobs* separados. Los tests *end-to-end* se pueden repartir en varios ejecutores. El tiempo total pasa a ser el del *job* más lento, no la suma.

3. No repetir trabajo entre etapas

Si la etapa de build compila el proyecto y luego la de test lo vuelve a compilar, estás pagando dos veces. Compartir el artefacto compilado entre *jobs* elimina esa duplicación.

Cómo montar el pipeline completo, con sus etapas y sus *gates*, está en la guía de integración y entrega continuas.