Tema: Explicación del concepto de promociones y pipelines en Integración Continua Categoria: Explicación concreta / Integración continua Tecnologías / Componentes: Jenkins y plugins Una de las tantas ventajas de tener un servidor de integración continua es poder tratar cada versión de un proyecto como una línea de producción, conocido en inglés como Pipeline.
Una linea de producción es realmente un conjunto de actividades automatizadas y ejecutadas en serie. Estas actividades pueden ser
Estas actividades son un ejemplo de lo que se puede hacer en una línea de producción, la cual puede contener todas o más actividades.
 En general se puede decir que una linea de producción realiza 4 grandes pasos:
1. Construcción . Esto incluye compilacion y pruebas unitarias y de análisis de código 2. Aceptación de usuario. Implica pruebas automatizadas de aceptación y estress asi como validación manual del usuario. 3. Despliegue. Incluyendo sus respectivas pruebas de validación en tantos ambientes se requiera. 4. Liberación. Implica liberar el código, artefactos finales y documentación. PromocionesExiste un concepto llamado Promoción (promotion) que es el paso intermedio entre cada una de estas actividades. Al terminar cada actividad satisfactoriamente se puede marcar esa versión como lista para ser promovida para que le sea aplicada la siguiente actividad.
Por lo tanto, Pipeline es el proceso general y Promotion es la marca de que una versión es elegida para poder pasar a la siguiente actividad. Es importante notar que cada pipeline debe ser aplicada sobre una misma versión por lo que hay que contemplar una manera de que la primera actividad al terminar satisfactoriamente guarde el código fuente y su compilado para pasarselos a la segunda actividad ; esta deberá ejecutarse sobre esta copia y pasársela a la siguiente actividad y asi sucesivamente. De esa manera podemos garantizar que la versión que se puso en producción con la última actividad es la misma que empezó todo el proceso y pasó por cada una de las pruebas, sin importar si en medio de la ejecucuion de la linea de producción comenzó otra vez la primera actividad con una versión diferente.
La pregunta puede ser ahora: y cómo comienza la primera actividad de la linea de producción?
General y recomendablemente la primera actividad deberá iniciar automáticamente cuando el repositorio o controlador de versiones, como subversion o git, fue actualizado. Por lo tanto, la única actividad que deberá estar escuchando y ser inicializada por el SCM (source control manager) deberá ser la primera y las consecutivas deberan ser inicializadas o automáticamente por su antecesora o manualmente por un usuario pero únicamente cuando ya ha sido promovida para esa actividad.  Para saber como inicializar una actividad de Jenkins cuando se esta usando Subversion puede verse en el artículo "Subversión y Jenkins: cómo comunicarse entre ellos"
Plugins en JenkinsDentro de Jenkins podemos utilizar varios plugins:
Copy Artifact PluginEste plugin sirve para poder guardar una copia y pasárselo a la siguiente actividad. Por lo tanto, tiene dos facetas: una para ser ejecutada como Post-build donde le indicamos qué es lo que se quiere guardar; y otra para ser ejecutada como Pre-build donde le indicamos qué queremos obtener, de qué actividad y de cual versión; es decir, para obtener una copia guardada podemos seleccionar si queremos de la actividad antecesora e inicializadora para asegurar tener la versión indicada o poder obtener la ultima versión satisfactoria. EtcLa configuracion para la primera faceta es la siguiente:
 Para la segunda faceta deberemos de configurara la siguiente pantalla en la actividad predecesora:
 Promotion Build PluginEste plugin sirve para hacer y marcar visualmente las promociones y nos da la ventaja que cada versión la va marcando con estrellas de diferentes colores por lo que en una vista general podemos ver todas las versiones compiladas y su nivel de promoción a la que llegó. Al hacerle click a cada versión nos mostrará el detalle indicando el número de job único de cada actividad.este plugin tiene que ser configurada en dos partes. Dentro de cada actividad deberemos configurar una tarea Post-build que inicialize otra actividad. De esta manera estaremos haciendo la ejecución seriedada de las actividades.  También en la primera actividad deberemos configuara el plugin de Promotion donde indicamos las estrellas y el color que deseamos en la finalizacion de cada actividad predecesora.   De esta manera se podrá ver cada versión y su status de promoción con estrellas.
 Build Pipeline PluginEste plugin funciona de una manera diferente ya que las actividades tienen que estar serializadas (como en el primer paso del plugin anterior) pero deberemos crear una vista nueva llamada pipeline view la cual fue instalada con el plugin. Al crear esta vista deberemos indicar cual es la primera actividad y detectara las predecesoras. Esta vista mostrara en una tabla el avance y estatus de cada linea de producción, donde cada renglon es una versión diferente y las columnas son cada una de las.actividades del pipeline. Cada actividad que ha sido ejecutada satisfactoriamente se pintara de color verde, las fallidas en rojo. Además, en caso que una actividad requiera de una aprobación manual o ser inicializada por una persona, en está vista aparecerá un botón para comenzar la actividad. M2 Release Plugin.Este plugin nos facilita la liberación del código en el repositorio SCM y etiquetarlos con un número final de versión. Así como liberar los artefactos finales en un repositorio de producción como Nexus.Es importante mencionar que este plugin funciona únicamente para proyectos Maven, y requiere las configuraciones pertinentes en el POM. Por lo tanto este plugin es una interfaz amigable de Jenkins para ejecutar los comandos mvn release:prepare release:perform Cargo pluginEste plugin nos sirve para desplegar artefactos web (war) en servidores web o de aplicaciones como Tomcat, Jboss, Websphere, etc.Igualmente que el plugin anterior, este es una interfaz de Jenkins para el respectivo plugin de Maven, por lo que, únicamente funciona para proyectos de este tipo.  BeneficiosLos principales beneficios para contar con una infraestructura y una técnica así son:
Recomendaciones para comenzar1. Comienza con algo, después irlo creciendo.Es importante tener un pipeline lo mas robusto y que abarque lo mas posible, sin embargo siempre se empieza con una actividad. Por lo tanto, primero comienzen con la actividad de compilación y pruebas unitarias y que esté integrado con el repositorio SCM. Una vez que se tenga dominada la activdad, sus resultados, su respectivo análisis y que el equipo esté acostumbrado a la herramienta pueden implementar otra actividad y no avanzar hasta que esta esté igualmente dominado. 2. Deja las pruebas rápidas al inicio. Debido a que es primordial el tiempo de respuesta al equipo, es importante que las actividades mas vitales estén al inicio y su ejecución sea la mas rapido posible.; por lo que las pruebas mas pesadas deberán dejarse para tiempos que no impacten en el tiempo de espera del equipo. 3. Hacer los commits al SCM lo mas frecuente posible. Muchos programadores no estan acostumbrados a ingresar sus cambios al repositorio de código o lo hacen una vez que ya terminaron el desarrollo. Sin embargo esto no es una buena práctica. Entre mas frecuentes sean los commits implicará que contiene muy pocas modificaciones por lo que si existe un error y el cambio rompió alguna dependencia será mas fácil encontrar el problema. En cambio, si el commit conlleva muchos cambios, será mucho mas difícil saber cual de todas las nuevas funcionalidades fue la del problema. 4. Siempre estar pendiente del pipeline y estatus de cada versión. Debemos desarrollar un hábito para ver y analizar cada pipeline y proyecto. En caso que alguna activdad no la estemos analizando o pensemos que no aporta información es mejor eliminarla, ya que implica que dicha actividad no nos es util actualmente. 5. Nunca subir algún cambio si no se ha probado localmente. No por subir cambios lo mas frecuente posible implica no probarlo localmente y estar seguros que al menos la compilación y pruebas unitarias son satisfactorias. 6. Nunca dejar los pipelines rotos o con errores. Es una muy mala práctica subir los cambios e irnos y en caso que algo se rompa dejarlo para mañana. Debemos acoatumbrar al equipo a mantener siempre en verde ya que si en algun momento empezamos a dejar actividades en rojo la gente se va acostumbrado y poco a poco mas actividades irán dejándose en rojo también 7. Ningún proyecto es pequeño para incluirlo. Es un error pensar que las lineas de producción y la integración continua per-se, es para proyectos o empresas grandes. Recordemos que cada actividad es repetible, automatizada y deja resultados, por lo que inclusive en proyectos chicos después de abandonarlos un tiempo cuesta trabajo retomarlos, saber el estatus en el que se dejó, recordar su funcionalidad original etc. Por lo que sería facil recurrir a la ejecución de la línea de producción para recordar y retomarlo rápidamente Así que, al implementar una infraestructura de pipelines es importante comunicar al equipo hacia donde se pretende ir y darles a conocer la importancia de su compromiso diario que eventualmente se hará hábito; de cualquier manera, esas buenas costumbres se quedarán arraigados en su propia formación y madurarán también junto con el proyecto. ¡Así que ánimo y los invito a ir implementando este método de trabajo! |
Página principal >