Durante mucho tiempo, en mi equipo el pipeline era "cosa mía". Si algo se rompía en el build, todos miraban hacia mi escritorio. Y yo, la verdad, me sentía cómodo con ese papel: era mi feudo, nadie tocaba el YAML sin preguntarme. Hasta que me fui dos semanas de vacaciones y el equipo quedó bloqueado tres días por un cambio de versión que nadie sabía dónde tocar.
Ahí entendí que un pipeline que solo una persona entiende no es una fortaleza, es un punto único de fallo con nombre y apellido. El mío.
Lo primero que hice al volver fue dejar de esconder la complejidad. Moví toda la lógica rara que tenía en scripts sueltos a pasos con nombres claros dentro del repositorio, junto al código de la aplicación. Nada de configuración mágica en la interfaz web del servidor de CI. Si no está en Git, no existe.
Después hicimos algo incómodo pero necesario: una sesión donde cada persona del equipo modificaba el pipeline en vivo. Añadir un test, cambiar un umbral de cobertura, romper algo a propósito y arreglarlo. La primera media hora fue puro miedo. La segunda, empezaron a proponer mejoras que yo nunca había visto porque estaba demasiado cerca del problema.
El cambio real no fue técnico, fue de propiedad. Cuando una desarrolladora abrió un PR para acelerar la fase de instalación de dependencias con caché, supe que ya no era "mi" pipeline. Era nuestro.
Hoy tengo tres reglas. Primera: cualquier persona del equipo debe poder leer el pipeline y entender qué pasa, sin preguntarme. Segunda: los cambios al pipeline pasan por revisión como cualquier otro código, ni más ni menos. Tercera: si un paso necesita un comentario largo para explicarse, es que el paso está mal diseñado, no mal documentado.
El pipeline dejó de ser un cuello de botella el día que dejó de ser mío. Y yo dejé de ser el rehén de mis propias vacaciones. Ganamos todos, sobre todo yo.
– Sergey Shinder
Top comments (0)