Home

martes, 22 de mayo de 2012

Anatomía del Proceso de Entrega Continua


En el post anterior (enlace a http://blog.dbaccess.com/2012/04/entrega-continua-un-enfoque-para.html),  conversamos sobre la propuesta del enfoque de entrega continua, como práctica para mejorar la calidad de los servicios de las empresas que desarrollan software. A continuación presento un gráfico (extraído del libro: Continuous Delivery por Jez Humble y David Farley Página 111), que representa, a unos 500.000 pies de altura, los componentes más básicos del proceso de Entrega Continua.


De la Figura podemos desprender los siguientes componentes importantes:
  • Sistema de Control de Versiones: En este sistema se resguarda todo lo necesario para la construcción, pruebas, empaquetamiento y despliegue del producto de Software, es indispensable poseer una herramienta que permita resguardar toda la información del producto.
  • Repositorio de Artefactos: Es otra herramienta transversal, en ella se almacenan los binarios o ejecutables del producto de software y están disponibles a lo largo de todo el proceso automatizado.
Adicionalmente, podemos detectar varias fases o etapas que componen a un proceso automatizado de construcción, pruebas y despliegues de un producto de software:
  • Fase de construcción: En esta fase, apoyados por un Sistema de Integración Continua, se extrae, del sistema de control de versiones, los últimos cambios realizados sobre el producto por un miembro del equipo de desarrollo, de forma automática se ejecutan las pruebas unitarias, pruebas de integración y componentes, se corren análisis estáticos del código fuente y se generan los ejecutables, se ensambla el producto y se guardan estos ejecutables en el repositorio de componentes para hacerlo accesible a las siguientes fases.
  • Fase de Aceptación: Es en esta fase donde el producto se recupera del repositorio de componentes y se realiza de forma automática la preparación de todo el ambiente requerido para la ejecución de pruebas del software en un ambiente lo más parecido o idéntico al ambiente de producción. El ejecutable es sometido a una serie de pruebas funcionales y de aceptación automatizadas y al finalizar tenemos la confianza de que el artefacto está apto para ser entregado en manos del cliente.
  • Fase de Desempeño: En esta fase, el producto puede ser sometido a pruebas de stress y de volumen de datos grandes, generados por un proceso automatizado, donde es posible evaluar aspectos de desempeño y comportamientos en entornos similares a producción y detectar problemas que típicamente se dejan de lado en el desarrollo. En esta etapa se chequean los llamados requerimientos no funcionales del sistema.
  • Fase de Aprobación (UAT): Las pruebas exploratorias por parte del cliente no pueden ni deben ser automatizadas, sobretodo, cuando se trata de medir aspectos como usabilidad y navegabilidad que son un poco más subjetivos, es por eso que en esta fase, el proceso permite que se despliegue la aplicación en ambientes para pruebas manuales, pero estos despliegues pueden ser realizados por los propios equipos de pruebas, el equipo de infraestructura del cliente o cualquier rol que tenga los privilegios para hacerlo, es decir, el despliegue y configuración del ambiente es un proceso automatizado que se realiza a petición y en algunos minutos. Minimizando las complicaciones que involucran preparar un ambiente con estas características.
  • Producción: Finalmente y una de las ventajas más importantes del proceso, la fase de Producción permite al equipo de operaciones del cliente desplegar, usando el mismo proceso validado en las fases previas, una versión del producto de software en un ambiente para los usuarios finales, con tan solo presionar un botón y eliminando el alto riesgo que típicamente involucra un despliegue en este tipo de ambientes.
Es importante destacar que basado en las prácticas de Integración Continua, cada cambio realizado sobre el producto de software dispara una instanciación del proceso automatizado y esa versión del producto, que debe ser una versión estable, se convierte en una versión estable + ∆, donde ∆ se espera que sean funcionalidades muy pequeñas que se desarrollaron en poco tiempo y cuyo riesgo de que agreguen defectos a la versión estable es menor.

Autor: Juan Bustamante

No hay comentarios: