Verificar local: el CI no es el lugar donde se descubren los errores
Tres pushes seguidos para arreglar un error de tipos que el chequeo local mostraba en quince segundos. Qué conviene correr antes de pushear, y cómo se ordena la verificación cuando el servidor es chico y hay varias cosas corriendo.
El ciclo es reconocible: se pushea, el pipeline falla por un error de tipos, se arregla, se pushea de nuevo, falla por el formato, se arregla, se pushea. Tres corridas de varios minutos cada una para resolver algo que localmente se veía en quince segundos.
No es sólo tiempo perdido: es atención fragmentada, porque entre push y push uno se fue a otra cosa.
Para qué sirve cada cosa
| Dónde | Qué corresponde verificar ahí | Por qué |
|---|---|---|
| Local, antes de commitear | Tipos, formato, tests del alcance tocado | Es lo más rápido y lo que más falla |
| Local, antes de pushear | La suite completa y el build | Es exactamente lo que va a correr el pipeline |
| El pipeline | Reproducir en un entorno limpio y publicar el artefacto | Verifica que no dependa de la máquina de nadie |
Esa última fila es su valor real: garantizar que lo que funciona en una máquina funciona en un entorno limpio, con las dependencias declaradas. Usarlo como primer detector de errores desperdicia ese rol y alarga el ciclo.
Un orden que no cuesta nada
De más barato a más caro
- Chequeo de tipos. Segundos, y atrapa la mayoría de lo que rompe el pipeline.
- Formato y reglas de estilo, que además evitan el ruido en el diff.
- Los tests de lo que tocaste. No la suite entera: el archivo o el módulo.
- La suite completa y el build, una sola vez, antes de pushear.
El costo que no se ve
Cuando el pipeline corre en un servicio con minutos incluidos, cada push fallido consume una cuota que se agota. En un mes de tres pushes por arreglo, el gasto se multiplica por tres.
Antes de seguir, predecí
Y hay un efecto sobre el equipo: un pipeline que falla seguido por errores triviales entrena a ignorar el rojo, y el día que falla por algo importante nadie lo mira distinto.
Que no dependa de acordarse
Tres formas, de menos a más
- Un solo comando de verificación en el proyecto, que corra todo lo que corre el pipeline. Si hay que recordar cuatro comandos, alguno se olvida.
- Un gancho previo al commit para lo barato —tipos y formato— y sólo para eso: si tarda más de unos segundos, la gente lo saltea.
- La misma definición en los dos lados. Que el comando local y el paso del pipeline ejecuten exactamente lo mismo, para que no haya sorpresas por diferencias de configuración.
Más a fondo · nivel seniorCuando el pipeline sí tiene que encontrar algo
Hay verificaciones que no conviene correr localmente: matrices de versiones, pruebas contra servicios reales, análisis de dependencias que requieren red, escaneos que tardan. Ésas son el trabajo legítimo del pipeline, y ahí el ciclo largo se justifica. La distinción es entre lo que falla por algo propio —que se ve local en segundos— y lo que sólo se puede comprobar en un entorno que uno no tiene.
Las tres corridas que se podían evitar
Buscá en el log
Tres corridas del pipeline para un cambio de dos archivos. ¿Qué línea muestra el error que se veía localmente en quince segundos?
debug 0info 8warn 0error 412 de 12
Un error de tipos, que es exactamente lo que verifica un typecheck local de quince segundos. Costó una corrida de seis minutos, más el tiempo de darse cuenta, más la vuelta a un contexto que ya se había soltado. Y las dos corridas siguientes son iguales: formato y una prueba, las dos cosas que la máquina propia responde antes. Lo que corresponde al pipeline es lo que la máquina propia no puede: el entorno limpio, la matriz de versiones, el despliegue.
Qué corresponde a cada lugar
| Dónde | Qué verifica | Por qué ahí |
|---|---|---|
| El editor | tipos y formato mientras se escribe | el ciclo más corto posible |
| Antes del commit | formato y linter sobre lo que cambió | segundos, y sólo sobre lo tocado |
| Antes del push | tipos y tests rápidos | quince segundos contra tres minutos de pipeline |
| El pipeline | entorno limpio, matriz de versiones, tests lentos, despliegue | lo que la máquina propia no puede |
Cierre
Autoevaluación
¿Lo entendiste?
Práctica