Has oído historias de mineros, ¿verdad?
Trabajar en la mina siempre ha sido una profesión arriesgada: en cualquier momento, los túneles se podrían llenar de gases letales e imposibles de detectar. A los mineros se les ocurrió un truco sencillo para reducir este riesgo: llevarían siempre con ellos un canario (ya que estas aves son más sensibles a los gases), de manera que, si la mina empezaba a llenarse de gases tóxicos, el canario moriría primero, y los mineros sabrían que tenían que salir rápidamente antes de correr la misma suerte.
Resulta que estos relatos inspiraron a los desarrolladores de software, llevándoles a idear sus propias maneras de percibir el peligro en sus actividades antes de que se convirtiese en un problema irremediable para las aplicaciones. Diseñaron los “canary releases” – una mejor práctica para gestionar los lanzamientos operativos que permite mostrar una nueva funcionalidad a un subgrupo reducido de usuarios para testearlo, e identificar los fallos que podrían aparecer en un entorno real. Si hubiese un defecto crítico, el canary release se lo revelaría a los desarrolladores antes de que la funcionalidad llegase a la base de usuarios más amplia, donde causaría daños mayores.
Está claro que los desarrolladores de software no estaban salvando sus vidas – pero sí la del software que estaban creando. Descubrieron cómo reconocer y arreglar rápidamente los fallos, recopilar datos de utilización reales para optimizar el software, y reducir el riesgo general en las etapas cruciales en las fases de desarrollo y lanzamiento.
Los product managers saben que gestionar los canary releases se ha convertido en una tarea imprescindible. Incluso un solo error podría echar abajo varios meses de trabajo duro, si no llegas a identificarlos mientras sean problemas pequeños y manejables.
La buena noticia es que podrías evitar esta potencial crisis si realizas un canary release… y si lo haces rápida, fácil e inteligentemente, planteándote tres preguntas cruciales.
|
Pregunta 1: ¿A qué usuarios deberías invitar a tu canary release?
Ésta es una cuestión fundamental para la que no existe, desgraciadamente, una única respuesta ‘correcta’. El grupo de usuarios específico que elijas dependerá de la naturaleza exacta de tu canary release y de lo que desees lograr.
A grandes rasgos, aquí se representan dos escuelas de pensamiento:
- Lanzamientos a tus usuarios ‘actuales’
- Lanzamientos a tus usuarios ‘potenciales’
|
La primera escuela de pensamiento, la de los usuarios ‘actuales’, defiende que deberías lanzar tu canary release a los usuarios pioneros, quienes te ofrecerán feedback de los fallos que identifiquen. Básicamente, éstos son los usuarios a quienes sabes que les gusta tu marca y tus productos, y que suelen comprarlos. Tras seleccionarlos, les dirás por adelantado que van a ver algunas funcionalidades nuevas que hay que terminar de pulir, por lo que deberían esperar algún bache.
Es fácil ver el lado positivo – podrás obtener feedback (¡y datos!) de usuarios que estarán trasteando con tus nuevas funcionalidades en un entorno real; y lo estarás haciendo de la manera más segura posible.
El negativo, por otra parte, es más difícil de reconocer: el hecho de estar lanzando tus nuevas funcionalidades a tus usuarios ‘actuales’ te impedirá garantizar que su feedback es completamente sincero… Ya que este grupo suele estar compuesto de usuarios pioneros y avanzados, será imposible asegurarte de que probarán las nuevas funcionalidades – y que podrán sortear las cuestiones técnicas – de la misma manera que los usuarios habituales.
La segunda escuela de pensamiento, la de los usuarios ‘potenciales’, afirma que simplemente deberías elegir un grupo de usuarios aleatorios, a quienes podrías dar (o no) un aviso previo de que van a testear funcionalidades nuevas (y, potencialmente, defectuosas).
Es notablemente más arriesgado realizar dichas pruebas con este grupo de usuarios, aunque éstos te aportarán la información más sincera, realista y práctica. Verás cómo una amplia gama de usuarios reacciona a tus nuevas funcionalidades, obtendrás feedback más franco (especialmente si algo no está funcionando correctamente), y, en general, podrás hacerte una idea mejor de qué ocurriría si lanzases hoy la nueva funcionalidad de tu producto.
Dicho esto, ¿qué grupo de usuarios deberías elegir?
Al final, la opción más popular es elegir una base de usuarios que caiga en un punto intermedio entre estos dos extremos. Seguramente optarás por una segmentación y personalización avanzada para lanzar tus nuevas funcionalidades a un grupo de usuarios que sea relevante y apropiado para las características específicas que estarás testeando; y que, simultáneamente, esté lo suficientemente bien segmentado para proteger tu imagen de marca si el lanzamiento no sale bien.
Efectivamente, con el enfoque correcto, puedes incluir a ambos grupos, ya que realizar test con distintos usuarios te permite obtener más feedback útil. Ahora, incluso realizar varios test – con distintos grupos de usuarios, para distintas funcionalidades – es más fácil que nunca.
|
Pregunta 2: ¿Qué funcionalidades testearás con tu canary release?
Esta pregunta es bastante sencilla. Siempre podrías lanzar un canary release para un conjunto de funcionalidades relativamente limitado; pero, en los últimos años, la variedad de opciones de las que dispones ha aumentado notablemente. ¡Aquí te presentaremos los cambios más relevantes!
Tradicionalmente, hacía falta una cantidad considerable de recursos para lanzar los canary releases. Podrían poner en peligro tu código base; su mantenimiento requeriría, seguramente, de mucho tiempo, atención y esfuerzo; y podrían ralentizar radicalmente el proceso de desarrollo. Siempre que quisieras lanzar un canary release, tendrías que garantizar que valdría completamente la pena – y esto limitaba mucho los tipos de funcionalidades que se testeaban.
Por lo general, sólo compensaba realizar un canary release para funcionalidades cruciales de alta visibilidad que fuesen fundamentales para la aplicación, como modificaciones a gran escala de un grupo entero de funcionalidades o de un detalle crucial de tu aplicación. En general, no se justificaba utilizar tantos recursos para realizar un canary release para testear una sola funcionalidad menor.
Naturalmente, esto limitaba las opciones de las que disponías: te impedía ser rápido, ágil y responsive. Tendrías que esperar hasta que estuviesen listas suficientes funcionalidades para lanzar antes de poder testear incluso una de ellas, y no podrías optimizarlas rápidamente empelando el feedback y los datos que recibieses de tu lanzamiento. En pocas palabras, tu canary release no sería particularmente ágil.
Actualmente, con el enfoque correcto, tendrás mucha más flexibilidad acerca de qué funcionalidades podrás testear con tu canary release. Ahora, puedes realizar cualquier test que desees – independientemente de lo pequeños y aislados que puedan ser; todo en un entorno real y con un gasto operacional razonable.
Te enseñamos cómo en la tercera pregunta…
|
Pregunta 3: ¿Cómo vas a realizar tu canary release?
La razón detrás de que los canary releases requiriesen tantos recursos era que, tradicionalmente, todos los procesos eran (hasta cierto punto) manuales.
Tenías que averiguar alguna manera de enviar la versión actualizada de tu aplicación sólo a un grupo específico de usuarios. Además, había que gestionar, configurar y monitorizar las modificaciones a corto y a largo plazo de tu código; y realizar un seguimiento manual de cada grupo de usuarios a través de los distintos test, documentando su utilización, feedback, y cualquier otro KPI en el que el test impactaría directamente. ¡Y habría que hacerlo todo manteniendo una funcionalidad impecable en la versión estándar de tu aplicación!
En resumen, el proceso entero requería muchísimas horas, era propenso a errores, y era imposible realizar test rápidos y sofisticados, incluso para los mejores equipos.
|
¿Qué ha cambiado desde entonces? En una palabra: el software.
Ahora, puedes automatizar la mayoría de los procesos necesarios para realizar un canary test; además, con la plataforma adecuada, podrás:
- Diseñar y configurar el test entero
- Testear numerosas funcionalidades (independientes entre sí)
- Diseñar múltiples segmentos y experiencias de testing altamente personalizados
- Lanzar todos tus test con un solo clic
- Monitorear el rendimiento de cada funcionalidad y grupo de usuarios en tiempo real
- Realizar todo tú mismo (¡ahorrando, simultáneamente, una cantidad de tiempo notable!)
|
Lo mejor de todo es que emplear la plataforma correcta servirá para reducir aún más el riesgo asociado a un canary release. Con un sencillo feature flag, podrás activar y desactivar, en cualquier momento, las funcionalidades individuales que estés testeando, en función de su rendimiento en tiempo real. De esta manera, evitarás retirar el lanzamiento entero si los resultados de una única funcionalidad no son satisfactorios – bastará con desactivarla para aquel grupo de usuarios específico, y dejar que el resto siga adelante.
Hemos agrupado todas estas funciones, y muchas más, en nuestra plataforma, Flagship. Defendemos que los canary releases son un elemento fundamental para cualquier plan de desarrollo ágil, y hemos trabajado para que realizarlos sea lo más fácil, sencillo y rentable posible.
Puedes aprender más acerca de nuestra plataforma aquí, ¡y empezar a lanzar tu primer canary release!
