No es raro encontrarse con numerosos commits en el historial de Git, dedicados a corregir pipelines. Esto ocurre porque probar pipelines puede ser complicado y, en Ășltima instancia, la Ășnica manera de verificar si realmente funcionan es hacer push del cĂłdigo y observar su comportamiento.
A lo largo de los años, he probado varias estrategias para simplificar las pruebas de pipelines, y estas son las âmejores prĂĄcticasâ que me funcionan.
Encapsular la funcionalidad en scripts
Un enfoque prĂĄctico es encapsular la mayorĂa de los pasos en scripts (bash, PowerShell, Python, Make, etc.). Esto facilita probar la pipeline localmente sin depender de frameworks ni herramientas complejas. No solo te permite probar la mayor parte de la funcionalidad en local antes de hacer push del cĂłdigo, sino que ademĂĄs acelera la depuraciĂłn gracias al feedback inmediato.
Utilizar un linter
Utilizar un linter es muy recomendable siempre que estamos desarrollando código, y eso incluye las pipelines. Utiliza un Entorno de Desarrollo Integrado (IDE), como Visual Studio Code, que incorpore un linter para el lenguaje y esquema de pipeline que estés usando. Esto ayuda a detectar errores de sintaxis y fallos comunes antes de hacer push del código.
Evitar herramientas para pruebas locales
Aunque puede resultar tentador usar herramientas que emulen localmente el entorno de la pipeline, creo que este es un enfoque arriesgado. El entorno de la pipeline es complejo, lo que hace difĂcil replicarlo con precisiĂłn en local. Esto puede generar una falsa sensaciĂłn de seguridad y llevar a subir cĂłdigo que no funciona. AdemĂĄs, en pipelines complejas, depender de una emulaciĂłn local puede terminar añadiendo cĂłdigo innecesario, con la consiguiente sobrecarga de mantenimiento y posibles fuentes de bugs.
Trabajar en una rama dedicada
Cuando no estĂ©s seguro del funcionamiento de la pipeline (que deberĂa ser siempre), crea una rama nueva para hacer pruebas. Esto te permite hacer push del cĂłdigo y evaluar su comportamiento sin afectar a la rama principal. Una vez que tengas confianza en que funciona, fusiona la rama en la principal usando un squash merge para mantener un historial limpio.
Un ejemplo real
Recientemente desarrollé una GitHub Action diseñada para minificar archivos HTML usando HTMLMinifier. En GitHub, un workflow (pipeline) debe estar definido en la rama por defecto antes de poder utilizarse. En consecuencia, empecé haciendo push del esqueleto de la pipeline, con un contenido similar a hello world, a la rama principal. Después, creé la rama dev y comencé a trabajar en la pipeline desde Visual Studio Code.
ProbĂ© la pipeline localmente usando scripts de JavaScript que escribĂ. Una vez que verifiquĂ© que funcionaba, hice push del cĂłdigo a la rama dev. DespuĂ©s de probarla a fondo, donde encontrĂ© algunos problemas con el directorio de trabajo, hice un squash merge, integrando la rama dev en la rama principal y manteniendo un historial limpio.