Si buscas resultados distintos, no hagas siempre lo mismo. ¡Desarrolla software de manera heterodoxa!

Liberación Continua de Software: el buque

La Liberación Continua de software (“Rolling Release software”) es un modelo que se ha ido extendiendo en los últimos años gracias al auge del Internet y la madurez tecnológica de los usuarios. En Pandora FMS anunciamos en marzo de 2017 el lanzamiento de la versión 7.0, a partir de la cual comenzamos la Liberación Continua de software. Pero, ¿qué significa esto? ¿Qué ventajas supone? ¡Echemos un ojo!

Introducción a la Liberación Continua de software

Como mencionamos, desde la versión 7.0 en Pandora FMS hemos adoptado el modelo de Liberación Continua de software, por lo que la manera en sí misma de numerar las diferentes versiones involucra un cambio notable. Así, anteriormente utilizábamos la manera tradicional de versionado y luego a partir de la versión 6 la acompañamos de diferentes Paquetes de Servicio («Service Pack» o “SP” por su abreviatura en inglés).

En un breve resumen os mostramos cómo ha evolucionado a lo largo de los años la denominación del versionado (en Wikipedia tenéis un excelente artículo con mayores detalles):

• Versión 1.0: octubre de 2004.
• Versión 2.0: septiembre de 2008.
• Versión 3.0: diciembre de 2009.
• Versión 4.0: agosto de 2011.
• Versión 5.0: octubre de 2013.
• Versión 6.0: noviembre de 2015.
• Versión 7.0: marzo de 2017.

Liberación Continua de software

No es poca cosa el estudio de este modelo de desarrollo de software y podríamos escribir miles de palabras que seguro que ambas partes disfrutaríamos; no tenemos miedo al trabajo duro, no. Pero oigamos lo que dijo un gran inventor de la antigüedad:
“La simplicidad es la máxima sofisticación”
Leonardo Da Vinci

Aquí seguiremos el consejo del legendario italiano y os explicaremos con un ejemplo práctico el concepto de Liberación Continua de software.

Somos diseñadores náuticos

Imaginad que somos un ingeniero naval y un astillero nos contrata para construir un bote. Nos especifica el número de pasajeros, la manga, la eslora y el propósito del mismo (pesca, competencia, etcétera). Este pequeño proyecto no representará problema alguno para nuestros conocimientos y no necesitaremos mayor arte para realizarlo. De igual manera, un pequeño software que realice un pequeño trabajo no representará ningún contratiempo para desarrollarse.

Un barco para cruzar el Mediterráneo y visitar las islas griegas

Pues resulta que ahora ese astillero nos contrata para diseñar un crucero que pueda albergar miles de personas, con comodidades específicas y según las leyes de la Unión Europea. Así dedicaremos varios años a los jefes de proyecto porque para nosotros en solitario es muy difícil de realizar.

Imaginemos, además, que vivimos a principios de 1900: deberemos de contratar cientos de diseñadores y miles de constructores, obreros especializados que sepan interpretar planos y con conocimientos mínimos de ingeniería pero con mucha destreza en las labores manuales. Veamos paso a paso cómo va esta obra.

Requerimientos

Aquí es esencial que nos entreguen por escrito las características del barco a diseñar, los países que visitará, las comodidades que tendrá y sobre todo la expectativas que tenga el cliente final que va comprar el barco.

Diseño

Aquí nos reuniremos con nuestros compañeros ingenieros navales y asignaremos equipos con diferentes propósitos: los que diseñarán la proa, otro grupo los camarotes, la sala de máquinas, las cocinas y comedores, etc. Cada quien sabe lo que tiene que hacer, al menos en teoría.

Implementación

En la fase de diseño se fabricarán las diferentes partes del barco mientras en el astillero habrán recibido nuestros planos y escogido el dique seco para comenzar a construir la coraza y de manera paralela irán llegando los componentes. Este proceso de construcción moderno está inspirado en la cadena de procesos inventada por Henry Ford y el concepto de inventario justo: solo estarán las piezas, partes y materiales cuando se armarse la nave.

Verificación

En el astillero no podrán armar el barco sin más: al tomar las partes que componen la nave habrá que medir y pesar para confirmar que están diseñadas según las copias de planos recibidas. Una vez se haya confirmado que todo está bien es que será izado por las grúas. En esta fase nos daremos cuenta de los errores de diseño: si el motor o motores recibidos están conformes a los planos y se procede a su montaje, justo allí nos daremos cuenta que no caben en la sala de máquinas o que sobresale alguna pieza que impide su introducción. No solamente con errores de diseño tendremos que lidiar; puede que suceda que un grupo de diseñadores haya realizado el mismo trabajo que otro grupo y no el suyo propio; una confusión en las asignaciones y tendremos trabajo repetido perdido y, además, trabajo por hacer. La verificación trata también de eso, de lo que falta por recibir para comenzar el armado.

Aquí comenzarán las pérdidas de tiempo y dinero para ajustar y no perder todo el esfuerzo y trabajo realizado, si es que tiene alguna solución.

Mantenimiento

Una vez superados todos los escollos veremos nuestro flamante buque listo para que proceda a flotar en aguas del puerto para sus primeras pruebas. La fase de mantenimiento comienza apenas se humedece; aunque esté correctamente pintado y con electricidad circulando por sus partes metálicas, la lucha contra la corrosión será hasta el final de sus días de utilidad.

Modelo en cascada

Lo que acabamos de explicar son las actividades del proceso de desarrollo de software pero realizadas según el modelo en cascada, lo cual tiene sus ventajas e inconvenientes:

• Se tiene control central del proyecto, los esfuerzos son bien direccionados.
• Es difícil que se exceda el costo inicial ya que al estar todo planificado solo se deben seguir al pie de la letra las pautas y cronograma.
• Lo malo es que el proceso es secuencial: hasta que no es superada una fase no se pasa a la siguiente.
• Si el astillero olvidó hacernos alguna especificación, el agregarla significa un mayor coste.
• Cuando lleguen materiales y piezas y empiece el armado y soldadura es cuando nos percatamos de los fallos de diseño.
• El astillero no participa en el proceso de diseño, por lo que sus observaciones no nos son retribuidas para corregir o mejorar el diseño.

Un barco realizado según la Liberación Continua de software

Bienvenidos al siglo XXI

A estas alturas, bien entrado este siglo, en la labor de diseñar y construir nuestro “gran barco de lujo” con nuevas herramientas, precisamente de software, podremos avanzar y mucho. Si bien las actividades de desarrollo de software se repiten (porque construir un barco siempre perseguirá, a la final, el mismo objetivo) la manera o el modelo que escojamos hará la diferencia.

Específicamente haremos uso de nuevas herramientas de diseño que expandirán nuestros horizontes.

Requerimientos

El inicio es casi igual al ejemplo que propusimos pero con una gran diferencia: los requerimientos los podremos volver a visitar para modificarlos o incluso adicionar más exigencias, sigamos leyendo y veremos cómo.

Diseño

Aquí se notan las diferencias del modelo: la Liberación Continua de software implica la Integración Continua de software acompañado o no de la Implementación Continua de software.

Recapitulando y simplificando serían: Integración, Liberación e Implementación (continuas de software).

Volvamos a nuestra nave: en la fase de diseño nuestros colegas ingenieros navales trabajarán en sus diseños asignados con el software CAD (y no podrán escoger otro porque sus credenciales de usuarios no se lo permitirán) y una vez consideren que hayan finalizado una meta planteada lo “subirán” al resto del proyecto que está ubicado en un repositorio el cual no solamente es un simple lugar de almacenamiento. Una ventaja temprana es que se podrá determinar automáticamente si lo propuesto por un grupo incide en otro grupo de trabajo, alertando para que podamos decidir qué se asimila y qué se descarta (esto se denomina colisiones).

Pero la parte más importante es que contaremos con un software que tomará todos los planos (en realidad dibujos hechos en tercera dimensión de manera virtual) y verificará primero cada uno de los componentes individuales asignados a cada equipo y luego armará la embarcación completa virtualmente, tras lo cual producirá un informe del resultado indicando qué posibles errores se encontraron y si se han excedido los requerimientos del proyecto.

De conseguir algún inconveniente le será posible comunicarse con los responsables del hecho para que tomen las medidas necesarias y no avancen más allá. Otra ventaja es que podemos asignar credenciales a los equipos en el astillero para que vaya revisando y haciendo sus observaciones para que el proyecto tenga una integración completa.

Implementación

Los componentes que ya están diseñados se pueden ir fabricando y llevando al puerto a fin de ir ganando tiempo. De aquí podemos retribuir al proyecto que dichas piezas arribaron y permite confirmar la salud cronológica de la creación.

Verificación

De igual manera se pueden ir verificando los componentes e ir subiendolos al repositorio para que cada que vez que los diseñadores “suban” sus pasos realizados y se realiza el armado virtual se confirme que lo que ya está físicamente corresponde a lo que acaban de diseñar. Aquí se puede notar incluso si “nos sobran partes” y así volver al diseño (o el jefe de proyecto decidir si prescinde de dicha parte definitivamente). Esto se contabilizará como pérdida, incluso si logran vender a buen precio el material, el tiempo perdido (diseño y manufactura) no podrá ser recuperado, pero la buena calidad del producto será salvada.

Mantenimiento

Una vez esté en el mar comienza la fase de mantenimiento; todos asociamos con reparaciones menores y mayores pero también pueden haber otros eventos que impulsan de nuevo el diseño: ahora el barco está destinado a ser un transatlántico para visitar las islas del Caribe, donde poderosos vientos impulsan el oleaje por lo que deberemos agregar unos estabilizadores… ¡y de nuevo a la “mesa” de diseño a repetir el ciclo para devolver el navío al astillero!

Liberación Continua de software

Ahora sí podemos hablar con propiedad acerca del desarrollo de un programa. Hablando con propiedad sobre las definiciones:

• La Integración Continua (“Continuous integration“) se centra en la integración del trabajo de los desarrolladores individuales en un repositorio principal varias veces al día, para detectar errores de integración de manera temprana y acelerar el desarrollo colaborativo.
• La Distribución Continua (“Continuous delivery“) tiene que ver con la reducción de la fricción en el proceso de implementación o liberación, la automatización de los pasos necesarios para implementar una compilación para que el código se pueda liberar de forma segura en cualquier momento.
• La Implementación Continua (“Continuous deployment“) va incluso un paso más allá, al implementarse automáticamente cada vez que se realiza un cambio de código.

Integración continua

Como explicamos en el ejemplo del diseño del barco, la Integración Continua de software consiste, a grandes rasgos, en que los programadores al finalizar el día (e incluso varias veces al día) incluyan todo su trabajo de nuevo al repositorio. Pero, ¿cómo funciona esto? Para explicar el control de ramas de software necesitamos revisar un poco la historia para saber de dónde venimos y hacia dónde vamos…

Linus Torvalds, rsync y git: pequeño resumen

En 1998 para Linus Torvalds ya era difícil coordinar el desarrollo del kernel de Linux, y no es hasta el año 2000 cuando nace un software capaz de controlar las versiones de una manera práctica. En ese año llega Apache Subversion (abreviado como SVN). Pero Linus no estaba aún conforme, así que en 2002 deciden encomendar a una empresa el proyecto de un software para controlar las versiones de un desarrollo de software cualquiera, cosa que no salió como se esperaba. Si bien el programa presentaba importantes novedades, útiles por demás y aún vigentes, también era semi-privativo, lo que trajo roces con la comunidad de software libre. Como no hay mal que por bien no venga, Torvalds encomendó a Andrew Tridgell (padre también del rsync y Samba Server) realizar una solución, y resulta ser que rsync sería la base para ello. En 2005 nace así Git (y también ve la luz Mercurial, otro software de control de versiones) y para la fecha estas tres alternativas acaparan la mayoría del mercado de programación.

Una de las novedades que impuso Git fue la de que cada programador tiene a su vez una copia del repositorio principal, por lo que al tener todos y cada uno del equipo una copia del repositorio principal, si este desaparece siempre se puede recuperar por medio de la combinación de manera ordenada y lógica de cada una de las copias, por lo que el tema del respaldo de datos quedó prácticamente resuelto.

También impuso el desarrollo por ramas: un programador al tener una copia completa del proyecto puede abrir una rama en paralelo y “subir” de nuevo sus cambios, para que el equipo decida agregarlo a la rama principal o bien sea desecharlo de una buena vez. Con esto que aquí explicamos es más que suficiente, pero, ¿qué tiene que ver con la Liberación Continua de software?

Cortas ramas de desarrollo

Como la Liberación Continua de software depende de la Integración Continua, ésta debe hacerse frecuentemente y con ramas muy cortas, que deben ser incorporadas rápidamente a la rama principal. El objetivo de estos cortos desarrollos es echar mano de otro procedimiento novedoso.

Compilaciones frecuentes de software

Por medio de un software que constantemente está revisando el código fuente principal, primero aplicando pruebas de humo a los componentes individuales y luego al proyecto completo para luego compilar e incluso aplicar pruebas de remojo, se puede determinar de manera muy rápida y directa si los cambios recientes funcionan y cumplen con los parámetros del proyecto. Tal como recordamos en nuestro ejemplo de la construcción de un barco para pasajeros, las compilaciones automatizadas cada vez que actualizan el código fuente de manera frecuente permiten interactuar y revisar la cadena de procesos en el desarrollo de software.

Compilación condicionada de software

Este modelo automatizado nos trae un beneficio adicional: es posible agregar opciones nuevas para los usuarios pero que se encuentren desactivadas por defecto. ¿Y esto para qué? Pues para ofrecer a los consumidores alternativas.

Distribución Continua (Liberación Continua de software)

La Liberación Continua de software es la etapa siguiente a la Integración Continua. Esta consiste en poder ofrecer las nuevas actualizaciones de manera automática, modificaciones o mejoras hechas al software mediante la cadena de procesos. En nuestro repositorio de aplicaciones tendremos entonces publicados y listos para su descarga todos los ficheros necesarios para la nueva versión; ahora dependerá del software instalado del lado del cliente el conectarse al repositorio, buscar las diferencias y mostrarlas al usuario, ya sea mediante un aviso en el escritorio de nuestra aplicación o mediante un mensaje emergente discreto. Sin embargo, el usuario no necesariamente tiene que recibir un mensaje de que está disponible una actualización. Vayamos al siguiente nivel de sofisticación con simplicidad.

Implementación Continua

Imagina que tienes miles de clientes y todos, o al menos la gran mayoría, tienen expectativas de nuevas versiones que facilitan su trabajo diario. Cualquier mejora es siempre bienvenida.

Un día cualquiera se anuncia la publicación en nuestro repositorio y ¡zas!, miles de dispositivos conectados al mismo tiempo… Incluso aunque tengamos una Red de Entrega de Contenidos (“Content Delivery Network” o CDN) esto nos ocasionará ciertos inconvenientes. En primer lugar en nuestro repositorio; aunque tenga un balanceador de carga y servidores espejo del repositorio, en algún momento se sobrecargará o incluso colapsará. Y si tenemos un servicio de CDN nos dolerá al tocar las arcas de dinero de nuestra empresa, porque cuando el tráfico tiene un pico o aumento repentino este es cobrado de forma adicional.

Aquí interviene la Liberación Continua de Software, acompañada de la Implementación Continua: de hecho los cambios en cada versión son pequeños pero constantes.

Pero también la Implementación Continua permite que dichas actualizaciones sean descargadas e instaladas en segundo plano, pero desactivadas por defecto en espera del anuncio público correspondiente. Otra ventaja adicional es que también nos permite contabilizar qué empresas han decidido no actualizar para poder realizar un acercamiento o encuestas.

Ahora imaginad la cara de nuestros usuarios y usuarias al aparecer el aviso de una nueva versión disponible y a la pregunta de “¿Desea usted instalar la nueva actualización?” que acepten y que en cuestión de un minuto o dos el proceso esté flamantemente habilitado. ¿Recuerdan la compilación condicionada? La sorpresa y la satisfacción de un trabajo de actualización de software bien hecho y de manera transparente a nuestros clientes bien vale la pena por el duro trabajo de cambiar el modelo de desarrollo: la Liberación Continua de Software llegó a Pandora FMS para quedarse y es tremendamente útil.

Conclusión

Todo esto es posible por medio de la madurez tecnológica que hemos ido adquiriendo. Nosotros, que comenzamos a programar y guardar en discos flexibles en los 80, nos sentimos aliviados y con gran expectativa acerca de esta tremenda oportunidad que se abre para todos, una hoja de ruta nueva.

Y recordad, “Pandora FMS” significa “Flexibilidad” y las “Rolling Release” definitivamente lo demuestran. Nuestro compromiso de llevaros la herramienta de monitorización en software libre más potente del mercado. ¡Feliz aprendizaje!