Integración Continua: Promociones y Líneas de Producción
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.
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
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.
Importante
Cada modificación el código original deberá pasar por toda 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.
Plugins en Jenkins
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
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.
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.
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.
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.
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.
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.
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.
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
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.
- emontoya's blog
- Inicie sesión o regístrese para enviar comentarios