A lo largo de los posts anteriores hemos ido avanzando en la transformación de nuestra organización hacia DevOps. Hemos visto cómo elaborar el Value Stream Map de nuestro proceso de entrega de valor, hemos visto distintas herramientas metodológicas que nos van a ayudar a gestionar nuestro proceso como son Lean Thinking y la teoría de las limitaciones. Además hemos articulado nuestros equipos enfocándolos a equipos multifuncionales y auto organizados. Por último, hemos analizado el conjunto de herramientas DevOps que nos van a servir para llevar a cabo nuestro cometido.
Armados con todo esto, en este post vamos a abordar un elemento clave de cara a automatizar nuestro proceso de entrega de valor al cliente. Este elemento clave es el patrón denominado “Deployment Pipeline”.
Qué es una Deployment Pipeline: definición y conceptos clave
Lo primero es definir qué es una Deployment Pipeline. Como siempre, voy a dar mi visión personal, remitiéndoos a fuentes específicas para una descripción más exhaustiva. En este caso, el libro “Continuous Delivery. Reliable Software Releases Through Build, Test and Deployment Automation” de Jez Humble y David Farley es una referencia de obligada lectura. De hecho, un tercio del libro se dedica a la descripción del patrón Deployment Pipeline.
Desde mi punto de vista una Deployment Pipeline es la implementación visual y automatizada de parte de nuestro Value Stream Map incorporando elementos de automatización en aquellos puntos que son susceptibles de automatizarse.
Los conceptos claves de esta breve descripción son “visual” y “automatización” pero que implican otros, como son aumentar el feedback y aumentar la confianza en el proceso.
Beneficios de usar una deployment pipeline:
- Aumento de la rapidez. Con un proceso automatizado en vez de manual la velocidad de ejecución es mucho mayor, por lo que los tiempos de ciclo se reducen, indicador fundamental en DevOps.
- Se obtiene un proceso repetible. Derivado del uso de la automatización obtenemos un proceso que se va a ejecutar siempre igual y que se puede repetir en distintos entornos.
- Aumento de la confianza en el proceso. Una deployment pipeline se puede ejecutar multitud de veces diariamente, lo que hace que aumente la confianza en el proceso.
- Aumento de feedback. Si algo va mal inmediatamente todo el equipo lo detecta y puede (y debe) corregirlo hasta que la pipeline vuelva a estar operativa.
- Convergencia y congruencia de entornos. El proceso automatizado de provisionado y despliegue favorece que los distintos entornos sean congruentes en el tiempo.
- Una única fuente de verdad. Al usar el servidor de control de versiones como origen de la pipeline, éste se convierte en el lugar en el que se puede consultar la información de todo el proceso.
Diseño de la deployment pipeline
Ahora que conocemos qué es una deployment pipeline y los beneficios que nos proporciona su uso, es momento de diseñarla. Para ello nos debemos apoyar en nuestro Value Stream Map para trasladarlo a la pipeline. Hay que tener en cuenta que el Value Stream Map incluye pasos que no se pueden automatizar, como son la generación de ideas, el diseño o la codificación. Es decir, nuestra deployment pipeline automatizada comienza en el momento en el que el trabajo intelectual se ha terminado. Ese momento realmente se produce cuando un miembro del equipo hace un commit de su trabajo en el servidor de control de versiones. Este evento desencadena una instancia de nuestra deployment pipeline y se va a propagar a lo largo de ella.
En esta primera etapa, comúnmente conocida como Commit Stage, se realizan distintas tareas:
- Compilación del código.
- Ejecución de tests unitarios.
- Análisis de la calidad de código: estilo, cobertura, complejidad.
- Generación de artefactos. Si todo es correcto se generarán los artefactos y se almacenarán el algún sitio para su uso en posteriores etapas.
Es aquí cuando tenemos el primer punto de feedback. Si algo de lo anterior fallara se pararía la línea y habría que corregirlo. Es importante hacer notar que esta etapa debe ser muy rápida para que el feedback sea adecuado.
Una vez que hemos pasado la Commit Stage podemos pasar a la etapa de despliegue a un entorno de test y ejecutar los distintos tipos de tests. En esta etapa tenemos las siguientes tareas:
- Despliegue de los artefactos generados en la commit stage al entorno de test. Es importante que sean los mismos artefactos y no se reconstruyan por entorno.
- Smoke test del despliegue. Es fundamental hacer un testing inicial para verificar que el despliegue se ha hecho correctamente. Si esto falla ya no tiene sentido perder el tiempo en las siguientes pruebas.
- Ejecución automatizada de tests de integración.
- Ejecución automatizada de tests de Aceptación.
- Se puede incluir test exploratorio manual o se puede dejar este tipo de testing para otro entorno.
- Se puede incluir testing no funcional, como son pruebas de rendimiento, seguridad, etc. Al igual que antes, estas pruebas se pueden dejar para otro entorno.
Si todo es correcto, en este punto podemos avanzar a la siguiente etapa en el pipeline. Hay que tener en cuenta que esta etapa es más lenta y habrá que considerar esto a la hora de diseñar el pipeline. Por ejemplo, si los tests de aceptación tardan mucho se podría paralelizar su ejecución.
En este segundo punto de feedback ya tenemos confianza en que nuestro código se despliega y se ejecuta de acuerdo a las especificaciones o tests de aceptación. Se puede repetir este proceso con tantos entornos como se desee, teniendo en cuenta que cuanto más avance en elpipeline los entornos se deben parecer cada vez más al entorno final de producción.
Idealmente todos los entornos deberían ser idénticos a producción, pero esto no siempre es posible.
Por último, si todas las pruebas en nuestros entornos de tests han sido satisfactorias, se podría lanzar la etapa de despliegue a producción. El proceso de despliegue debe ser idéntico al realizado con los entornos anteriores. Las tareas a realizar en esta etapa serían las siguientes:
- Despliegue al entorno de producción.
- Smoke test del despliegue. Hay que tener en cuenta que hay que estar preparado para deshacer los cambios en caso de que algo vaya mal.
- Ejecución automatizada de un subconjunto de tests que permitan establecer el éxito de la release. Se usará un subconjunto para acelerar la posible detección de errores.
- Validación manual del despliegue.
Básicamente este sería el proceso de nuestra deployment pipeline que se puede ver en la siguiente imagen:
Una vez diseñada, se debe proceder a la implementación de la Deployment Pipeline, etapa en la que profundizaré en el siguiente post del blog. Síguenos en Twitter o LinkedIn para no perdértelo.
Emiliano Sutil es Project Manager en Xeridia
