¿Las releases pueden ser ágiles? Sí, y de hecho deben serlo.

Uno de los aspectos que más me han frustrado como comprador desde que se inició el “boom” del comercio online es el de la entrega del paquete, ya sea en mi hogar o en mi oficina.

Soy un consumidor plenamente autónomo capaz de completar un proceso de compra, desde la selección del producto hasta el pago con tarjeta de crédito. Sin embargo, en el último paso algo falla, me convierto en alguien dependiente de la empresa de reparto:

• ¿El paquete llegará el lunes o el martes?
• ¿Podré trabajar desde casa ese día para recogerlo?
• ¿Tengo confianza con mis vecinos para que lo recojan ellos?
• ¿Coincidirá justo con una reunión importante?
• ¿Mi dirección estará en el inicio de la ruta del repartidor o lo dejarán para el final del día?

Incluso en plena pandemia y trabajando desde casa pueden surgir complicaciones ,y por tanto, necesitamos cierta flexibilidad en la entrega. Pues bien, esta misma frustración sienten las personas de negocio de nuestra organización, más concretamente el Product Owner, cuando entregamos software.

Releases a la carta

Quizá estemos todos de acuerdo en que cuanto antes entreguemos valor al negocio, mejor. Pero hay muchos motivos que requieren consenso, estos son algunos de ellos:

• Aspectos legales: hemos detectado cambios de última hora que son necesarios para cumplir con la normativa vigente
• Dependencias funcionales: que lancemos una funcionalidad implica que tengamos que lanzar otra que aún no está lista
• Detección de bugs: son detectados en entornos inmediatamente anteriores a producción y son suficientemente importantes como para bloquear una release
• Estrategia de negocio: el desarrollo de la funcionalidad ha llevado más tiempo de lo esperado y por fin está lista. Pero... ¡un momento!, hoy es viernes y nos preguntamos si queremos lanzar algo que nuestros indicadores de negocio desaconsejan por volumen de ventas durante el fin de semana o cualquier otra métrica
• Usuarios target: están relacionados con la estrategia de negocio. ¿Y si quiero lanzar solo para cierto grupo de usuarios? Limitar una funcionalidad a los usuarios de una región o de un navegador concreto es algo muy común que me permite, entre otras cosas, testear la calidad y hacer A/B testing

Todos estos motivos y algunos más nos obligan a tratar los cambios incluidos en nuestra release como diferentes piezas con identidad propia y no como una única unidad. Por ello, dotar a nuestra organización de la capacidad de elegir qué funcionalidad se lanza y cuándo se lanza, se convierte en un recurso ágil de suma importancia.

Imaginaos que somos el Product Owner de nuestro hogar, donde el cuadro de fusibles es el software y cada fusible es una funcionalidad independiente. Si nos vamos de viaje es posible que queramos apagar todo menos la nevera y el acuario. Es, en definitiva, tener el poder de decir: “Este no, este otro sí, este no y este tampoco”. Para aplicar esta estrategia es importante saber distinguir entre despliegue y release.

Desacoplar despliegue y release

Seguramente todos o casi todos hemos vivido la siguiente situación:

• “Equipo, ¡estoy viendo la nueva funcionalidad en producción! ¿Qué ha pasado? No la queríamos hasta el día 14.” —Product Owner—.
• “Estábamos haciendo atasco en el pipeline y hemos tenido que tirar ‘palante’...”. —Dev Team—.
• “Esto es un problema gordo, ¿no podemos deshacerlo?”. — Product Owner—.
• “Uff, habría que hacer un rollback y entonces perderíamos el bugfix del login. Es peor el remedio que la enfermedad”. —Dev Team—.

La conversación seguiría con gestos de impotencia del Product Owner, y con razón. Esto ocurre cuando no distinguimos entre despliegue y release; es decir, cuando el hecho de completar un despliegue pone automáticamente la funcionalidad a disposición del usuario final.

Atendiendo a las definiciones de Beyond-Agility vemos que:

• Un despliegue es “una cuestión técnica, es llevar una nueva versión del software al entorno destino”. Como resultado, la nueva funcionalidad está presente en producción, que no es lo mismo que disponible.
• Una release es “una cuestión de negocio, es poner una funcionalidad disponible para el usuario final”.

Como véis, en el ejemplo de arriba el Dev Team no amplió el espectro de visión, sino que pensó únicamente en lo técnico. Así que por fin llegamos a la clave del asunto, eso que nos permite tomar el control de las funcionalidades.

Feature toggles

También llamadas funcionalidades activables/desactivables, feature flags, on/off o cualquier otro nombre que exprese el carácter binario de algo que puedo encender o apagar a mi antojo. Nos permiten definir diferentes tratamientos o estados incrementales. Vamos a ver un ejemplo práctico:

Supongamos que trabajamos en la web multi-región www.miwebagil.com y desarrollamos un banner situado en la cabecera de nuestra página de registro de usuarios. De acuerdo a las necesidades de negocio definimos los siguientes estados posibles:

1. Estado 0: el banner está oculto, por lo que la funcionalidad es transparente para el usuario final
2. Estado 1: el banner es visible solo para los usuarios que provienen de una landing page en italiano y que además navegan con Chrome
3. Estado 2: lo mismo que el estado 1 pero para usuarios de cualquier navegador
4. Estado 3: el banner es visible para cualquier usuario final sin condición alguna

Una vez se ha completado el despliegue y nuestros cambios están en producción en estado 0, esta aproximación nos permite ceder el control de las releases a las personas de negocio, que pueden cambiar la configuración mediante una interfaz de usuario, sin necesidad de más despliegues.

Si toda funcionalidad está arropada por un toggle lograremos hacer despliegues transparentes para el usuario final. Esta técnica favorece la Inspección y Adaptación ya que, a medida que cambiamos de estado la funcionalidad, podemos analizar nuestras métricas de negocio y pivotar la solución.

Podemos responder a preguntas como: “¿resulta atractivo el banner y se registran más usuarios que antes?”. Es un A/B testing, bastaría con comparar métricas entre estados o implementar estados con porcentaje de tráfico (solo el 50% de los usuarios ven el banner).

No es momento de entrar en aspectos técnicos ya que daría para otra publicación, pero cabe destacar que los toggles los implementamos en nuestro código fuente y por lo tanto pueden estar presentes tanto en backend como en frontend.

Aquí os dejo una buena explicación de Martin Fowler donde repasa las diferentes categorías de toggles y sus posibles usos. Estas son algunas de las soluciones más extendidas en el mercado: Launch Darkly y ConfigCat.

Una nueva forma de hacer releases

Bien, hemos visto cómo liberar funcionalidades de una manera flexible e incremental. Ahora vamos a recopilar las principales ventajas:

• Cedemos el control de las funcionalidades al negocio, que son los que saben mejor que nadie cómo y cuándo aportan más valor.
• Acabamos con los atascos en el pipeline y la situación de no poder ir para adelante ni para atrás por tener bugs o dependencias.
• Hacemos del despliegue algo cotidiano pero controlado, de manera que le perdemos el miedo.
• Aumentamos la resiliencia de nuestro sistema. Salvo catástrofe, el rollback es sustituido por un cambio de la funcionalidad a estado 0 y así no impactar negativamente al usuario durante más tiempo.
• Combinado con técnicas de Lean Startup como el trabajar con pequeños paquetes de cambios nos hará dinámicos y rápidos ante las eventualidades.

Y, como era de esperar, hay ciertos aspectos negativos a tener en cuenta. Los tiempos de desarrollo y QA aumentan debido a trabajar con diferentes estados de la funcionalidad.

Además, requiere una limpieza periódica de toggles en el código fuente cuando las funcionalidades ya están consolidadas en producción. De otra manera terminaríamos con una maraña de toggles que generan interdependencias.

La necesidad de contar con cierta flexibilidad a la hora de lanzar funcionalidades la aprendí trabajando en una de las grandes tecnológicas, donde adelantarse a la competencia y a la vez mantener impecable la experiencia de usuario era primordial.

Aprendí que no puedes tener un enfoque CD/CI si pierdes el control sobre tus cambios al final del proceso de release.

¿Quieres profundizar más aún?

¡No te pierdas este podcast!