Feature flags: tipos, vida útil y limpieza

Qué es

Un feature flag (también llamado feature toggle) es una condición en el código cuyo valor procede en tiempo de ejecución de una configuración, no del build. El artículo citado distingue cuatro categorías según su vida útil y su dinamismo: los flags de release ocultan trabajo inacabado en la rama principal (vida corta, estáticos); los flags de experimento reparten a los usuarios entre variantes (de horas a semanas, decididos por cada petición); los flags de operaciones limitan o desactivan funciones bajo carga (se activan a mano, normalmente de vida corta, aunque algunos permanecen como interruptores de emergencia); los flags de permisos («Permissioning Toggles») habilitan funciones para determinados grupos de usuarios (permanentes, por usuario). El artículo recomienda concentrar la decisión en un «Toggle Router» en lugar de repartir if flag por todo el código.

Por qué importa

Los flags hacen posible el trunk-based development, los despliegues graduales y la reversión rápida sin un nuevo despliegue. Pero multiplican los estados en los que puede encontrarse el sistema: con diez flags independientes hay 1024 combinaciones, de las cuales las pruebas cubren pocas. Los flags de release olvidados se convierten en bifurcaciones permanentes que ya nadie entiende.

Cómo aplicarlo

• Al crear cada flag, registrar: categoría, propósito, responsable, fecha de creación y fecha prevista de retirada. Los flags de release reciben una fecha de caducidad poco después de completarse el despliegue total.
• Mantener la lógica de decisión en un solo lugar: el código pregunta «¿está activa la función X en este contexto?», no «¿qué valor hay en la configuración?». La respuesta se inyecta como dependencia, de modo que las pruebas puedan forzar ambos casos.
• Probar ambos lados de un flag de release en el pipeline hasta que se retire: como mínimo, la ruta por defecto y la ruta con todos los flags en su estado objetivo.
• Hacer visible el estado de los flags por entorno (una página o un endpoint que liste todos los flags con su valor y su origen) y registrar los cambios.
• Planificar la retirada como una tarea propia: eliminar la condición, borrar la rama muerta, adaptar las pruebas y limpiar la configuración. Los flags vencidos aparecen en el backlog como cualquier otra deuda técnica.
• Los flags de operaciones y de permisos que deban permanecer se diseñan deliberadamente como configuración: documentados, con valor por defecto y con protección de acceso.

Trampas

Un flag que cambia formatos de datos no se puede revertir sin más una vez que se han escrito datos en el nuevo formato; para eso hace falta el patrón expand and contract. Si el estado de los flags se mantiene en varios sistemas, las incidencias se vuelven irreproducibles. Los flags que se consultan mediante una cadena con su nombre devuelven en silencio el valor por defecto si hay una errata. Un flag de experimento que se queda después del experimento mantiene vivas ambas variantes.