Podcast - ¿Las releases pueden ser ágiles?

Hoy en día los marcos de trabajo ágiles están muy extendidos, es incluso raro encontrar equipos que sigan enfoques tradicionales. Pero... ¿y qué pasa con las releases?

A menudo las buenas prácticas se diluyen a la hora de hacerlas. La necesidad de contar con cierta flexibilidad cuando lanzamos funcionalidades se acentúa en un mercado cada vez más competitivo, donde experimentar diferentes resultados, adelantarse a la competencia y mantener impecable la experiencia de usuario son aspectos diferenciadores.

En el podcast de hoy charlamos sobre estrategias de release, sobre el uso y los beneficios de utilizar Feature Toggles.

¿No sabes dónde escucharlo? Como siempre, encontrarás nuestros podcast en las principales plataformas: Ivoox, YouTube, Spotify, Apple Podcast y Google Podcast.

¿Qué son los features flags?

También llamadas feature toggles, es un mecanismo que nos permite hacer una release de una funcionalidad en caliente, es decir, cambiar el comportamiento de una aplicación sin necesidad de despliegue en producción.

Para entender los flags, hay que entender dos términos release y deployment (despliegue). El despliegue es una cuestión puramente técnica, es llevar una nueva versión de nuestro software a un entorno concreto. Que esté presente no significa que esté disponible para el usuario final. Mientras que release es una cuestión de negocio, es hacer que sí estén disponibles

Esto nos lleva a la importancia de desacoplar la release del despliegue, pero hay muchas condiciones para querer poner una funcionalidad disponible (condiciones legales, dependencias,bugs...). Y los flags permiten ese desacople.

¿Qué usos tiene?

Algunas de las funcionalidades de los flags:

• Rollback en caliente de una funcionalidad.
• A/B testing, en definitiva, experimentar.
• CD/CI: favorece el CD (despliegue continuo). Como parte de la mentalidad Agile deberíamos buscar equipos multidisciplinares, es decir, que además del desarrollo y el testing, también se responsabilicen de devops. Aquí encontramos organizaciones y equipos que no quieren hacerlo por la criticidad de un despliegue. Si contamos con flags, todas las funcionalidades van desactivadas por defecto. Le estamos quitando hierro al asunto. Infraestructura + toggles.
• Canary release. Nueva versión disponible solo para un grupo reducido de usuarios.
• Testing en producción: tests exploratorios sin asumir riesgos.
• Discriminar por grupos de usuario: región, por navegador, etc.

Flexibilidad a medida

El implementar flags requiere un esfuerzo extra. Lo primero a la hora de definir, refinar y estimar historias porque tenemos que tener en cuenta los posibles estados de funcionalidad.

A nivel código tendríamos bloques condicionales. Tenemos que evaluar el estado del flag y si podemos hacerlo en cualquier capa: BE, FE: si el flag está a cero, mostramos esto. etc.

Por otro lado, en la etapa de testing, ya sea manual o automática, hay que probar o desarrollarla en todos los estados.

Despliegue, release y después, una vez que la funcionalidad está consolidada en producción, si los resultados son buenos y hay aceptación de los usuarios, deberíamos eliminar el toogle, volviendo al código quitar todos los estados que pusimos y dejar solo un bloque de código con el estado final y que se ejecuta siempre.

En definitiva lleva tiempo y coste hacerlo pero te da la flexibilidad que necesites y una capacidad brutal de reacción de eventualidades y problemas.

Si te ha gustado el podcast, te recomendamos que no te pierdas este post: ¿Las releases pueden ser ágiles? Sí, y de hecho deben serlo.