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:

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:

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:

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:

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:

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.

Cuéntanos qué te parece.

Enviar.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete