Integración Continua: Promociones y Líneas de Producción

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
  • Compilación y comprobación de pruebas unitarias.
  • Colocación del artefacto compilado en un repositorio de Snapshots.
  • Pruebas de control de calidad en el código, por ejemplo con los analizadores estaticos como findbug pmd, etc o con Sonar.
  • Ejecución de pruebas de funcionalidad o de aceptación de usuarios.
  • Desplegar la aplicación en un ambiente de pruebas.
  • Ejecución de un tipo de pruebas tipo Smoke test o de integración para validar que el despliegue fue satisfactorio y configurado correctamente. 
  • Ejecución de pruebas de estré, por ejemplo con Jmeter
  • Liberación del código y su etiquetación como "Productivo"  y con un número de versión final.
  • Colocar el artefacto o compilado final en un repositorio de artefactos liberados como Nexus.
  • Despliegue del artefacto liberado en el ambiente productivo.
  • Ejecución de unas pruebas finales para validar que el despliegue fue satisfactorio.
  • Generación de la documentación final y su despliegue en un servidor web o de documentos.
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. 

Promociones

Existe 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.

Pipeline
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.

Importante
Cada modificación el código original deberá pasar por toda la linea de producción.

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 Jenkins 

Dentro de Jenkins podemos utilizar varios plugins:

Copy Artifact Plugin

Este 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.  Etc

La configuracion para la primera faceta es la siguiente:
Para la segunda faceta deberemos de configurara la siguiente pantalla en la actividad predecesora:

Promotion Build Plugin

Este 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 Plugin 

Este 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
 

Cargo plugin 

Este 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.

Beneficios 

Los principales beneficios para contar con una infraestructura y una técnica así son:

  • La confianza de todos los afectados (stakeholders) aumenta, ya que existe una manera de probar cada paso y tener evidencia de que no ha existido algún error que cause regresión. 
  • La participación de cada stakeholder se hace notar dentro del proceso completo.
  • optimización de tiempo y aumento de calidad, ya que cada actividad es automatizada y repetible disminuyendo error humano.
  • La valorizacion del equipo personal y profesionalmente incrementa ya que dejan tareas repetitivas y se enfocan a otras con mucho mas valor.
  • El tiempo de respuesta entre el equipo y el estatus de los proyectos es mínima.  Entre mas rápido el equipo sepa que una versión rompió alguna prueba o algún otro pipeline de otro proyecto dependiente, mayor será el tiempo de respuesta para corregirlo.

Recomendaciones para comenzar

1. 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

Hay que recordar que mejora continua es un proceso de madurez y no un cambio radical e impositivo. Y un proceso de madurez implica ciertos cambios lentos pero siempre constantes con la adopción de hábitos y costumbres.

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!


Post original en blog del autor