En estás líneas voy a tratar de describir de forma superficial, y esbozando mi visión, una serie de prácticas que están actualmente tomando bastante impulso en el mundo de la tecnología y que se hacen llamar, despliegue continuo.

El despliegue continuo es un conjunto de prácticas que permiten, sobre un entorno en producción generalmente basado en aplicaciones web, aunque posiblemente aplicable a otros tipos de aplicaciones, la reducción de los tiempos de despliegue, aumentando la seguridad de la versión desplegada, facilitando la detección de fallos y la posible marcha atrás en caso de ser necesario.

Y como se consigue esto que a priori suena muy bien, pues principalmente, reduciendo el número de cambios de las versiones que se entregan y aumentando el número de las mismas. El concepto es similar al utilizado en las metodologías ágiles de desarrollo. En vez de planificar un proyecto en su totalidad (waterfall), desde el inicio, hasta su supuesto fin, y en dónde en la mayoría de las veces no controlamos con exactitud que es lo que pasa más allá de dos semanas, siendo probablemente la planificación de meses o años, se hacen pequeñas planificaciones con lo que si está claro y se llevan hasta su desarrollo final, completando un hito. Tras iteraciones sucesivas en las que se van cubriendo el resto de funcionalidades, se consigue finalizar el proyecto. En el despliegue continuo una versión que puede llevar bastantes meses de desarrollo y preparación e incluye infinidad de nuevas funcionalidad y cambios, se trocea en versiones más pequeñas auto contenidas, que se van desplegando de forma independiente y con muchísima menor frecuencia.

Dicho esto, a los que venimos del mundo IT tradicional, nos es difícil entender como haciendo tantos despliegues y tan continuos, pensemos que encima, el riesgo de fallo en los mismos va a disminuir. Los defensores de este tipo de prácticas lo argumentan, no sin su lógica, de la siguiente manera.

Al ser las versiones muy pequeñas, tanto en cambios como en funcionalidad, el impacto que pueden producir en caso de fallo es mucho menor que si se estuvieran desplegando un gran número. Igualmente, en caso de que si se produzca un fallo, poder identificar la causa raíz del mismo es más sencilla, ya que no se ha cambiado demasiadas piezas del puzzle que suelen acabar siendo los servicios. Por último, dar marcha atrás también se simplifica, ya que los cambios realizados o nuevas versiones introducidas son reducidas y los tiempos para reemplazar la anterior funcionalidad menores.

Contado así, parece lógico e incluso podría convencerme, pero por otro lado me viene a la cabeza que cuantos más cambios haga al día, más posibilidad tengo de que haya más cortes del servicio, eso sí de menor tiempo de duración pero más frecuentes, lo que igualmente puede suponer una pérdida de credibilidad por parte de nuestros usuarios. Lo bueno es que esto también tiene remedio bajo el prisma del Despliegue Continuo, ya que este solo consiste en dividir una nueva versión, en múltiples más pequeñas, con menor funcionalidad y cambios, sino que tiene que ir acompañada de unas buenas prácticas y herramientas que aseguren de alguna forma que lo que se va a desplegar, aunque pequeño, sea seguro y fiable.

Y que buenas prácticas y herramientas son las que deben acompañar a la instalación de múltiples mini versiones para conseguir convencernos de que son fiables y seguros. Os las describo a continuación.

La primera de ellas y que me ha llamado bastante la atención, es la de desacoplar el concepto de despliegue al de versión. Para entenderlo, primero debo explicar que es cada una de ellas, o que se entiende. Despliegue consiste en poner en el entorno de producción la nueva versión, pero sin dejarla accesible a los usuarios. Este despliegue se convertirá en versión cuando realmente ya lo dejemos tocar y jugar al usuario con ella. Que conseguimos con esto, mantener ambas versiones sobre el mismo entorno, una estable, la versión en si mismo, accesible por el usuario y el despliegue, con las nuevas funcionalidades, listo para ser exprimido y probado por todas las pruebas que queramos realizar sobre él (smoke tests). Cuando el despliegue esté perfectamente probado y sea fiable, pasamos a conmutar la versión antigua, ya a la versión que contiene la nueva funcionalidad. En caso de que se haya escapado algo, ya que aunque acotemos al máximo los errores, por desgracia estos se resisten y hacen acto de presencia, volveremos a conmutar a la versión antigua.

Así contado me persuade, ahora por contra, se me hace complicado recordar entornos de los que he tenido el gusto de gestionar, en los que se pudiera separar tan fácilmente, a nivel de desarrollo, servidores web, de aplicaciones, y base de datos, la versión que se le presenta al usuario, del despliegue que se pone en el entorno de producción con nuevas funcionalidades, pudiendo así mismo cambiar uno por otro, de forma tan sencilla y clara como se explica más arriba. Quizás la solución sería que esto se contemplara desde un inicio, como uno de los requisitos necesarios e indispensables que se deben cumplir, dentro del diseño de la arquitectura software del servicio.

Otra de las buenas prácticas que se recomiendan es automatizar en todo lo que se pueda la cadena de producción de servicios. Con tal fin, la mejor propuesta de las que he podido ver es disponer de buenas herramientas, basadas o en software existente o en el desarrollo a medida de scripts. Conseguir que el software que se entrega en las mini versiones que se despliegan con frecuencia, tenga un buen grado de fiabilidad, se propone que al menos existan los tres entornos que os cuento en la próximas líneas.

Servidor continuo de integración: Es muy necesario y casi es uno de los elementos clave, el que exista un elemento centralizado donde se puedan ejecutar los tests (unitarios, funcionales, de integración), monitorizar los resultados obtenidos y ejecutar el despliegue en caso de que sean favorables. Más que citar productos que hagan esto, si que me gustaría recalcar el que la que se elija, sea capaz de poder acometer las acciones indicadas en este párrafo para todo el código utilizado en la organización, tanto en lenguajes como entornos.

Control de versiones: Es muy importante que todo quede recogido dentro del sistema de control de versiones, y cuando me refiero a todo, no solo hablo del código fuente, sino también de las máquinas virtuales para montar los entornos, hardware, así como los compiladores para crear los entregables. El fin no es más que poder reconstruir cada entregable y el entorno que se utilizó para su construcción, a partir de un número de versión concreto. Realmente aunque en teoría es lo que se debe de hacer, en el mundo real no veo muy claro el poder asociar hardware y otro tipo de aplicaciones que no es código fuente, pero si os confieso que no soy un experto en estos temas.

Herramientas de despliegue: Es prácticamente imprescindible disponer de scripts o de una herramienta que de forma incremental permita desplegar software de un servicio en todas las máquinas implicadas, permita chequear la salud de dichas máquinas y del servicio en general una vez hecho el despliegue y en caso de alerta por mal funcionamiento pueda revertir los cambios efectuados y volver a la antigua versión. Tan importante como esto es la necesidad de que todo el mundo para los despliegues utilice estos mecanismos y no otros, con lo que para facilitarles que sea así, deben ser lo más simples posibles y hay que asegurarse de que todo el mundo conozca bien como utilizarlos.

Como última buena práctica y no menos importante se sitúan en los grupos de operación, últimos receptores de los despliegues y máximos sufridores de los errores que se comentan durante fases anteriores. Hasta ahora hemos hablado de como facilitar la vida a desarrolladores y equipos de despliegue, pero que pasa con los grupos de operación. ¿Cómo pueden ver una ventaja en hacer tantos despliegues en el entorno productivo? Aquí la pregunta, más que la expuesta debería ir un poco más allá y ser la siguiente, ¿Cómo hacer que se pongan en sintonía los desarrolladores de software con los profesionales de IT?

Básicamente todo apunta a metodologías como DevOps, pero no me gustaría profundizar mucho ahora en ello para no desviar el tema. Únicamente comentaros una aproximación muy curiosa que he leído en torno a compaginar el despliegue continuo, con la gestión de cambios en IT, resumiéndose en dos puntos principales.

Aligerar el proceso de gestión de cambios, haciendo ver las ventajas que supone el despliegue continuo en relación a fiabilidad y seguridad de las versiones entregadas, como he descrito anteriormente.

Involucrar durante todo el proceso de despliegue continuo a todas los equipos, que de una u otra manera van a participar en el servicio y especialmente a los miembros que forman parte del comité de cambios.

Para finalizar y aún siendo escéptico, puedo dar mi brazo a torcer y pensar que en conjunto son unas buenas prácticas para el despliegue tanto de desarrollos que se hagan dentro de casa, como software comercial, o incluso ir un poco más allá y aplicarlo cuando sean necesarias una o varias actualizaciones de hardware.

«Eso es todo amigos…»