El objetivo de esta entrada es narrar la aventura de como llegue a jenkins y las opciones que tuve que descartar en el trayecto. Estuve mucho tiempo probando herramientas, también creando algunas otras.
La mayor limitante que tengo actualmente, es que solo tengo acceso a una cuenta de ftp, poco apoyo en el trabajo. y mucha apatia por mejorar. Entonces partiendo de estas premisas comencé a investigar y probar.
Rsync
Mi primera aproximación fue Rsync y la creación de flujo trabajo en la cual tenía dos directorios uno en la cual desarrollaba y otro como punto de referencia. El objetivo era obtener como resultado un directorio con todos los archivos que cambiaron entre el repositorio de desarrollo y el de referencia. Una vez que obtenía el resultado, actualizaba el repo de referencia con un pull. Pero aún tenía que subir manualmente el resultado aunque ya solo subia lo que había cambiado y no tenia que ver archivo por archivo o la clasica sube todo.
Problemas
Aún no era tan automático. pero almenos ya no tenía que ver qué cosas cambiaron.
GruntsJs
Mi siguiente mejora al proceso anterior fue utilizar un task runner GruntJs. Aplicando el concepto anterior y con la facilidad de gruntjs para crear comandos logre “automatizar” todo el proceso anterior e incluso poder subir el resultado por ftp, gracias a que a existia algo en gruntjs que podia subir un directorio por ftp. Vaya era una mejora significativa. Solo ejecutaba un comando en terminal y baang ya se subia todos los archivos y ejecutaba todo el proceso anterior.
Problemas
Sólo podía ejecutarse en mac y probablemente en linux, no sabía cómo encapsular todo en un solo script y que fuera multiplataforma.
Si por x o y razón el repositorio de referencia se dañaba el resultado terminaba haciendo un desastre.
Solo para inicializar o dejar todo el proceso funcionado era toda una odisea en la cual tenias que seguir pasos muy precisos y dificiles de seguir mas aun de recordar.
Replicarlo en varios proyectos también era muy complicado.
Dado todos los problemas anteriores decidí implementar casi obligar a utilizar ramas en el flujo de trabajo del equipo de desarrollo, de esta manera ya podría tener un antes y un después. Pero solo ayudo un poco.
Python haz lo tu mismo
Mi siguiente alternativa fue con un pensamiento, pues puedo programar al carajo deja lo creo. Pues que me agarro a desarrollar un comando en terminal utilizando python, no niego que fue muy educativo. Cual era el nuevo flujo de trabajo:
Cree una utilidad en terminal que me permitia ejecutar en un directorio que estuviera en git, crear una archivo de configuración, donde colocaba los acceso a ftp. con el api de bitbucket tenía toda la información disponible del repositorio ramas, commits acceso total.
Entonces con dos comandos o tres disponible podría inicializar proyecto y hacer deploy. el cual descargaba el repositorio en temporal y en base al api de bitbucket y comandos de git podía obtener la diferencia entre dos ramas y generar un directorio con las diferencias. Justo lo que obtenían en los puntos anteriores. Y ya existe librerías en python para subir archivos por ftp. entonces ya tenía un comando con lo que ocupaba… si si ya viene el pero.
https://github.com/fcarrizalest/iv-cli
Problemas
El api de bitbucket tenía problemas, por versión de python. por arquitectura Mac o Windows. Tenía que editar cosas manuales en las librerías Algo Horrible. Supongo que ya lo arreglaron.
El desarrollo estaba en su primera etapas, salían bugs extraños como lo anterior. Pero también había escenarios diferentes, peculiaridades en proyecto. Archivos que no debía subir, en donde tenía que subi o que direcotio sincronizar.
Era lento como tenia que descargar el proyecto cada vez, la comparación permisos de escritura.
Básicamente era continuar probando y tratar de encontrar todos los escenarios, pero lamentablemente estaba consumiendo mucho tiempo y lo tuve que dejar.
Bueno ya con todo el tiempo que ya le había dedicado, aunque no niego cada opción fue divertida, aun no tenia algo que me permitiera librame de ese trabajo. Entonces la magia de youtube y su capacidad de leerte la mente, llegue a una librería git-ftp y pumm, si si eso ocupo. e incluso el video lo integraba con pipelines de bitbucket.
Lo probé en mis repositorios de prueba y funcionaba, el problema, pues no tengo acceso de admin en bitbucket y nunca me dieron los accesos asi que comence a explorar alternativas de cómo ejecutarlo. Lo pude ejecutar lcoalmente, con algunos problemas pero no tenía comparación con lo que vi en el video que era Automatico. solo hacías commit y pum ya se actualizaba. Yo tenía que ejecutar el comando manualmente (Si tenia flojera de hacerlo de esa manera, sabiendo que se podía hacer de otra manera).
Fue cuando encontré Jenkins
Jenkins de alguna manera es similar a los pipelines que bitbucket ofrece, pero con la ventaja que tu controlas todo. Lo personalizas, ademas de estar pensado para trabajar con repositorios y muchas ramas. Con una serie de plugins capaz de extender la funcionalidad basica y valgame que tienen plugin para todo. Poder ejecutar Scripts, poder correr imagenes en docker. pff se puede hacer tantas cosas, y por cada commit que se realice.
Bueno aun tengo problemas pero ya son menores, como que a veces no quiere subir css. Si un miembro del equipo hace un commit en otra rama. Se hace todo un desastre.
Añadir nuevo comentario