¿Qué es entrega continua?

Una de las definiciones mas acertadas de lo que significa entrega continua esta dada por el autor Jez Humble y dice:

“La entrega continua es la habilidad de llevar cambios nuevos de cualquier tipo (características, configuraciones, correcciones, y experimentos) a producción o a las manos del usuario, sin peligro y rápidamente”

Esta definición cubre los puntos clave en lo que a la entrega continua respecta.

Para entender mejor, imaginemos un escenario en donde somos los responsables de un producto. Digamos que el producto es un sistema de mensajería interna. Los usuarios finales tienen un requerimiento: quieren adjuntar documentos a sus mensajes de texto. Estimamos que el desarrollo de esa nueva característica nos tomara una semana, ¿cuando podría el usuario final usarla?. Usualmente después de que el desarrollo esta concluido se lo entregamos de primero al equipo de calidad y después al equipo de operaciones, lo cual se toma un tiempo que varia desde días a meses en entregar. Entonces aun cuando el desarrollo solo toma una semana el usuario tarda en recibirlo un mes. El proceso de entrega continua busca entonces automatizar las tareas que conlleva el entregar software terminado al usuario final con la finalidad de entregar características tan pronto como se han terminado.

Pero para entender mejor como automatizar el proceso de entrega en un sistema sin entrega continua es necesario que describamos el proceso de entrega usado tradicionalmente por los equipos que desarrollan software.

El proceso de entrega tradicional

Cualquier proceso de entrega comienza con los requerimientos definidos por el cliente o interesado, y termina con un lanzamiento a producción. La diferencia entre la entrega tradicional y la entrega continua reside en el proceso. Y se puede definir por medio del siguiente diagrama:

El ciclo de lanzamiento comienza por lo requerido por el dueño del producto quien representa a los clientes. Después hay tres fases, durante las cuales el trabajo pasa por diferentes equipos:

• Desarrollo Los desarrolladores, a veces en conjunto con los analistas de negocio, trabajan en el producto. A menudo usan técnicas de desarrollo ágil como scrum o kanban para incrementar la velocidad del desarrollo mejorar la comunicación con el cliente. Se organizan sesiones demostrativas para obtener retroalimentación. Todas las buenas practicas de desarrollo (como desarrollo dirigido por pruebas) son bienvenidos. Después de que la implementación esta terminada se pasa al equipo de aseguramiento de la calidad.
• Aseguramiento De la Calidad Esta fase es usualmente llamada “Pruebas de Aceptación Del Usuario (UAT por sus siglas en ingles)” y requiere que se congele el repositorio de código, es decir que no cambie, para que no se incluyan desarrollos nuevos que puedan romper las pruebas. El analista de calidad lleva a cabo un conjunto de pruebas de integración, pruebas de aceptación, y de pruebas no funcionales como por ejemplo: pruebas de desempeño, resiliencia, seguridad etc… Cabe mencionar que al momento de encontrar cualquier defecto el trabajo regresa al equipo de desarrollo, así que el desarrollador siempre tiene una sobrecarga de trabajo. Después de que se pasa la fase UAT el equipo de calidad aprueba los cambios que fueron planeados para el siguiente lanzamiento.
• Operaciones En esta ultima fase, que usualmente es la mas corta, el código pasa al equipo de operaciones para que puedan efectuar el lanzamiento a producción y monitorear el comportamiento de los cambios en un ambiente de producción. Si algo sale mal, contactan a los desarrolladores para que los ayuden a detectar defectos en el ambiente de producción.

Deficiencias en el proceso de entrega tradicional

El proceso de entrega tradicional tiene varias deficiencias entre las que podríamos notar:

• Entregas lentas
• Ciclos largos de retroalimentación
• Falta de automatización
• Correcciones en caliente arriesgadas
• Estrés
• Comunicación dificultosa
• Responsabilidades compartidas
• Baja satisfacción de trabajo

Beneficios en el proceso de entrega continua

Por cada una de las deficiencias que la entrega tradicional presenta, la entrega continua antepone una solución,  podríamos notar algunas ventajas que son:

• Entregas rápidas
• Ciclos cortos de retroalimentación
• Lanzamientos de bajo riesgo
• Opciones de lanzamiento flexibles

Implementación del proceso de entrega continua

Al principio del post definimos que era el proceso de entrega continua y porque lo usamos. Ahora es momento de definir como implementarla.

Hay que hacer énfasis en que cada fase en el proceso tradicional de entrega es importante. De lo contrario este proceso nunca hubiera sido bien recibido. Nadie querría entregar un proyecto de software sin probarlo primero. El rol que juega la fase UAT es detectar defectos y asegurar que los desarrolladores han creado lo que el cliente quería exactamente. Lo mismo aplica para el equipo de operaciones, el software debe ser configurado e instalado en producción, y posteriormente monitoreado. Pero entonces ¿como automatizamos el proceso de instalar el software para preservar todas las fases? Y ese es el rol que juega precisamente la entrega continua y su proceso de instalación automatizada, el cual se puede representar con el siguiente diagrama:

Es necesario que dediquemos un tiempo a entender que significa cada una de las fases de la entrega continua, así que le dedico unos cuantos párrafos a la descripción de las mismas.

Fase de integración continua

Esta fase provee la primera retroalimentación a los desarrolladores. Consiste en detectar cuando se han introducido cambios en el repositorio que esta sistema de control de versiones (git, svn, etc..), entonces de forma automatizada se obtienen los cambios, se compilan, se corren las pruebas unitarias, y se verifica la calidad del código. Si alguno de los pasos en esta fase falla la ejecución de la entrega continua se detiene y lo que los desarrolladores deben hacer es corregir cualquier error que se presente. La clave en esta fase es el ahorro de tiempo que supone que el los desarrolladores inicien el proceso de compilar y probar el código cada vez que hacen un commit al repositorio. Si hay fallos, estos son corregidos mucho mas rápido.

El proceso de integración continua es usualmente el punto de inicio. Su configuración es simple porque todo se hace desde el equipo de desarrollo y no se necesita ningún acuerdo especial entre los equipos de calidad y operaciones.

En posts ulteriores a este hablaré mas a fondo y con demostraciones menos teóricas el uso de las herramientas para esta fase.

Fase de pruebas de aceptación automatizadas

La fase de pruebas de aceptación automatizadas es un conjunto de pruebas escritas en conjunto con el cliente y los analistas de calidad que estarán a cargo de reemplazar el trabajo manual en la fase UAT. Actuando como una compuerta de calidad para decidir si el producto esta listo para ser lanzado o no. Si cualquiera de las pruebas de aceptación falla, entonces toda la ejecución de instalación se detiene y no se procede a las fases subsecuentes. Esto para prevenir que se ejecute la fase de gestión de la configuración y en consecuencia lanzar software defectuoso.

La idea de automatizar las pruebas de aceptación es construir un producto de buena calidad en lugar de verificar la calidad del producto cuando ya esta en producción. En otras palabras, cuando el desarrollador completa la implementación, el software se entrega con las pruebas de aceptación ya hechas que verifican que el software es lo que el cliente desea. Esto cambia por completo el paradigma de “probar el software” pues ya no es necesario que una persona o un equipo de personas intervenga en el lanzamiento de nuevo software. Pero todo depende en pasar el conjunto de pruebas de aceptación. Por eso crear esta fase es usualmente la parte mas difícil del proceso ya que requiere mucha colaboración con el cliente y crear las pruebas al principio del desarrollo y no al final.

Usualmente hay mucha confusión en los tipos de pruebas y el lugar que ocupan en el proceso de entrega continua. También queda poco claro como automatizar cada tipo de pruebas, cual tendría que ser la cobertura y cual sería el rol del equipo de calidad durante el proceso de desarrollo. Para ello tenemos 2 herramientas didácticas que son la matriz de pruebas ágil y la pirámide de pruebas.

Matriz de pruebas ágiles

Brian Marick, introdujo este concepto en una serie de posts e hizo una clasificación de pruebas en forma de una matriz. Coloca las pruebas en dos dimensiones: Orientadas al negocio o la tecnología y al equipo de soporte y las criticas del producto. La clasificación es así:

• Pruebas de aceptación automatizadas: Representan todos los requerimientos funcionales vistos desde una perspectiva de negocio. Están escritos en la forma de una serie de historias de usuario o ejemplos por los clientes y los desarrolladores que acuerdan como debería funcionar el software.
• Pruebas unitarias automatizadas: Son pruebas que ayudan a los desarrolladores a lograr software de alta calidad y minimizar el numero de defectos.
• Pruebas exploratorias manuales: Estas son las pruebas de “caja negra” las cuales tratan de romper o mejorar el software en cuestion
• Pruebas no funcionales automatizadas: Son las pruebas que representan un sistema de propiedades relacionadas a el desempeño, seguridad etc..

Esta matriz contesta la pregunta ¿Cual es el rol del equipo de calidad en todo el proceso?

El aseguramiento de la calidad manual realiza las pruebas exploratorias. Ellos juegan con el sistema, tratan de romperlo, hacen preguntas, piensan en como mejorarlo. Y automatización del aseguramiento de calidad se encarga de escribir pruebas automatizadas para la aceptación, las pruebas unitarias y las no funcionales.

Pirámide de pruebas

El concepto de la matriz de pruebas contesta algunas preguntas sobre lo que los tipos de pruebas representan en el proceso, pero no dice nada sobre cuantas pruebas deberíamos desarrollar. Cual debería ser la cobertura en caso de pruebas unitarias, o de aceptación.

Para contestar esas preguntas, Mike Cohn, en su libro Succeeding with Agile: Software Development Using Scrum ha creado el concepto de la pirámide de pruebas.

Si miramos la pirámide en la parte de arriba, las pruebas se vuelven cada vez mas lentas y caras para crear. Usualmente se requiere experimentar con la interfaz de usuario y contratar a un equipo de automatización por separado. Es por eso que las pruebas de aceptación no deberían tener como objetivo el 100% de la cobertura. Por el contrario, deberían estar orientadas a las características y verificar solo escenarios seleccionados, de lo contrario gastaríamos una fortuna en el desarrollo y mantenimiento de esas pruebas, y nuestro proceso de entrega continua tardaría mucho tiempo en ejecutarse.

Esta situación es diferente a la que se ve en la parte baja de la pirámide. Las pruebas unitarias son baratas y rápidas, así que el objetivo de la cobertura debería ser del 100%. Son escritas por los desarrolladores y proveerlas debe ser un procedimiento estándar de un equipo maduro.

Fase de gestión de la configuración

Esta fase es la responsable de llevar el control de los cambios en el ambiente (de producción, desarrollo…) del software. Su principal utilidad es la de instalar y configurar las dependencias necesarias para que el software funcione correctamente, escalar la cantidad de instancias de los servicios y su distribución, inventario de infraestructura, y todas las tareas relacionadas con la instalación de la aplicación.

Es la solución a los problemas que conlleva instalar manualmente y configurar las aplicaciones en producción. Estos problemas surgen usualmente cuando es difícil llevar el control de que esta corriendo donde y con que propiedades. Las herramientas de gestión de la configuración, tales como

• Ansible
• Chef
• Puppet

Nos facilitan el almacenar las configuraciones en archivos en un sistema de control de versiones y llevar un control de todos los cambios realizados en los servidores de producción.

Un esfuerzo adicional es reemplazar las tareas manuales que el equipo de operaciones tiene que hacer para monitorear la aplicación. Esto se logra transmitiendo bitácoras y métricas de los sistemas a un tablero que a su vez es monitoreado por los desarrollados o por un equipo de DevOps.