Objetivo Integración Continua
Tras algunos acontecimientos subí de prioridad en mi cola “echar un vistazo a Jenkins”.
Una de las cosas que más me llaman la atención cuando voy a eventos es ver como algunos consiguen llegar a cabo la Integración Continua(CI a partir de ahora). Pensándolo detenidamente la verdad es que tiene aspectos positivos muy enriquecedores pero conseguirlo requiere por una parte mucho tiempo de asimilación, conocimientos y por otra la puesta en marcha sobre un proyecto concreto. Todo esto se traduce básicamente en tiempo.
Tenemos que balancear entre la recompensa por llevar a cabo CI sobre sus aspectos negativos. Obviamente mi objetivo no es pasar absolutamente todos los proyectos a CI, pero creo que si es un (proyecto propio O medianamente importante) Y se va a alargar en el tiempo los aspectos positivos sobrepasan a los negativos y merece la pena.
Tenemos que balancear entre la recompensa por llevar a cabo CI sobre sus aspectos negativos. Obviamente mi objetivo no es pasar absolutamente todos los proyectos a CI, pero creo que si es un (proyecto propio O medianamente importante) Y se va a alargar en el tiempo los aspectos positivos sobrepasan a los negativos y merece la pena.
Disclaimer: En la redacción del post empecé a escribir razonamientos, pros/contras sobre CI y prácticamente me daba para otro post entero. Así que en esta ocasión creo oportuno no extenderme en este apartado para no enfarragar el post.
Previsiones y Primeras Impresiones
Pues no tenía nada claro a lo que me enfrentaba, a pesar de haber escuchado sobre él y entender sus funcionalidades nunca me había puesto a reflexionar como eran los métodos de este mayordomo.
La verdad es que teniendo en mente el concepto de CI si lo mezclas con conocimientos básicos de alguna/s de las herramientas con las que interactúa(git, mvn, svn, email, shell) creo que la iconografía del mayordomo está acertadamente elegida.
Sinceramente puedo decir que tras una tarde pude conseguir grandes avances así que creo que no resbalaré si digo que el uso es realmente sencillo.
No quiero llevaros a error, si algo he aprendido en la vida es que aquellas cosas que tienen o requieren menos reglas son fáciles de USAR pero difíciles de USAR BIEN. Si vuestro objetivo es alcanzar la maestría en la herramienta nada más empezar creo que os equivocais de entorno.
Correr Jenkins desde War
Cómo no tenía mucha fe en la facilidad y no me veía usándolo a las primeras de cambio me decanté por usar el archivo war en vez de apostar por una de las opciones instalables.
Pasos
1. Ir a la página del proyecto http://jenkins-ci.org/
2. Descargarse el archivo war en la carpeta que creamos conveniente
3. Irte a la consola, y navegar hasta la carpeta que contiene el war
4. Ejecutar la siguiente línea
java -jar jenkins.war
5. Ir al navegador a la url(en vez de la ip puedes poner tu nombre de dominio local)
Listo ya puedes empezar a mandar tareas a Jenkins.
Plugins
Una vez dentro la verdad es que fuí directamente a la administración de Jenkins para ver que cosas podía tocar.
Lo que más me llamó la atención fué el apartado de Plugins, así que allí que fuí.
Detallo la lista de plugins que me instalé
-Bitbucket Oauth Plugin (En la propia página pasos a seguir para hacer setup)
Como veis nada del otro mundo.
La lista de plugins es enorme así que no creo que sea difícil que cada uno lo adapte a sus necesidades.
Queda claro que hay una gran comunidad detrás del proyecto que normalmente suelo traducirlo como un producto de éxito. No es nada fácil que los desarrolladores hagan plugins para herramientas de desarrolladores si éstas no les son realmente útiles y la usan en su día a día.
New Job
La forma de trabajar con Jenkins es prepararle una lista de acciones a realizar. El objetivo es explicarle lo que queremos hacer paso a paso. Le decimos cómo nos tiene que notificar cuando encuentre algún problema y a partir de ese momento puedes despreocuparte.
No me cansaré de decirlo durante el post, la palabra que se me viene siempre es la de facilidad.
Hacer una tarea para encomendar a Jenkins es FÁCIL. Os voy a comentar la configuración realizada para una WebApp con el código en Bitbucket y desarrollada con el framework CakePHP.
New Job ¿Cómo queremos identificar al trabajo?
Para empezar debemos asignar un nombre y una descripción. Si le asignamos muchas tareas a Jenkins, cuando nos avise de que algo va mal queremos que nos diga a que tarea se está refiriendo.
SCM ¿Dónde queremos que Jenkins vaya a buscar lo que necesita?
En mi caso el código lo tengo sobre git en Bitbucket, así que tan sólo le tengo que decir la URL del repositorio y con la rama concreta que quiero que trabaje.
Build Trigger ¿Cuándo queremos que Jenkins trabaje sobre esta tarea?
Puedes elegir una o varias opciones. En mi caso le digo a Jenkins que pase por bitbucket cada hora y mire si hay cambios nuevos en el repositorio, de ser así que empiece a trabajar.
Esta acción se llama Poll SCM, y debemos asignarle el tiempo a través de Cron. Puedes consultar cuando fué la última vez que se pasó Jenkins para comprobar actualizaciones por el repositorio.
Creo que lo ideal sería que cada vez que Bitbucket recibiera cambios en la branch concreta notificara a Jenkins, entiendo que esto es posible en caso de que tengas tu Jenkins corriendo sobre alguna IP accesible por Internet.
+19.03.24.png)
+19.03.24.png)
Build ¿Qué quieres que haga Jenkins?
Aquí puedes ir encadenando acciones que quiere que haga Jenkins una vez tenga tu código.
+19.04.33.png)
+19.04.33.png)
En mi caso y a través de los ejemplos en cakephp.org(Integración con Jenkins) genero a través de shell un par de archivos de configuración.
databases.php - La configuración de base de datos que quiero que tenga Jenkins
core.php - En este caso la configuración de la aplicación en entorno de desarrollo
Tras tener todo el sistema de fichero montados le paso dos tests de suites que tengo montadas.
Post-build ¿Qué tiene que hacer Jenkins después?
Después de hacer la tarea pueden pasar dos cosas en mi caso, que funcionen los tests o que no.
Le tengo dicho a Jenkins que si fallan los test me mande un correo para estar al tanto y en caso de que esta tarea haya fallado anteriormente y esta vez haya ido todo bien también me lo notifique para que pueda despreocuparme.
Me gusta de Jenkins...
Versatilidad
Que tenga muchas opciones en todos las partes del proceso de la tarea. Esto hace que sea muy configurable y puedas definirlo a tus necesidades aunque sean muy concretas.
La despreocupación por la tarea repetitiva.
Los primeras horas de uso pasaba tiempo mirando si hacía los builds cuando y como le había dicho que tenía que hacerlo (parecía demasiado fácil para ser verdad) pues increíblemente hacía lo que decía hacer.
El rápido feedback.
Tras un par de días de uso, con todos los builds pasando los tests, prácticamente me había olvidado de Jenkins cuando recibo un correo diciéndome que los últimos commits habían roto los tests, lo reviso lo arreglo y recibo el email de que todo vuelve a la normalidad. Eso tiene un nombre: Tranquilidad.
Siguientes Pasos
Ahora que ya tengo todo lo que es la parte de tests automatizadas me quedaría hacer un despliegue directamente desde Jenkins para acercarme al objetivo deseado de la CI. Aunque la parte de despliegue para producción requiera más detalle no creo que me lleve mucho tiempo si es parecido a la generación de pasos del Build
Tras evaluar el tiempo dedicado/ganancia obtenida puedo decir que tengo en alta estima el proyecto. Gracias a todos que dedican parte de su tiempo para hacerlo mejor.
No comments:
Post a Comment