Feature flags: activa nuevas funciones con control y sin acumular deuda

Una versión puede estar instalada en producción sin que todas sus funciones estén disponibles para todos los usuarios. Las feature flags permiten controlar esa activación y abrir una funcionalidad de forma gradual. Bien utilizadas, reducen la exposición inicial y facilitan detener un cambio problemático. Mal mantenidas, multiplican combinaciones, esconden comportamientos y complican las pruebas. Su valor depende tanto del diseño del código como de la disciplina con la que se decide quién las cambia y cuándo se eliminan.

Elige una finalidad clara para cada bandera

Distingue una bandera temporal de lanzamiento de una configuración operativa que debe permanecer. La primera acompaña una entrega y debería desaparecer cuando termina la transición. La segunda puede servir para desactivar una dependencia o ajustar un modo de funcionamiento. También existen experimentos, que necesitan criterios de medición propios. Mezclar estos usos bajo nombres genéricos hace difícil saber qué se puede borrar. Registra propósito, propietario y condición de cierre desde el momento de crearla.

Diseña la ruta segura cuando falta configuración

Decide qué ocurre si el servicio que proporciona la bandera no responde, la caché caduca o el valor es desconocido. La opción predeterminada depende del riesgo de la función y debe probarse. No supongas que activar o desactivar siempre es más seguro. Una bandera de mantenimiento puede tener implicaciones distintas a una de lanzamiento. Documenta también cuánto tarda en propagarse un cambio, porque un interruptor que parece inmediato puede convivir con valores antiguos durante un intervalo.

Evalúa la bandera en el lugar adecuado. Ocultar un botón en el navegador no sustituye la autorización en el servidor. Si la funcionalidad modifica datos o accede a recursos protegidos, sus comprobaciones deben mantenerse independientemente de cómo se presenta la interfaz. Evita incluir información sensible en reglas enviadas al cliente. La gestión de funcionalidades controla disponibilidad; no debe convertirse accidentalmente en el mecanismo de seguridad de una operación.

Activa por grupos estables y observa el efecto

Empieza por usuarios internos o un grupo pequeño con características conocidas. Mantén la asignación estable para que una persona no salte entre comportamientos en cada petición, salvo que el diseño lo requiera explícitamente. Relaciona la activación con errores, latencia y éxito de la tarea que cambia. Una apertura gradual no aporta protección si nadie observa el resultado o si los criterios para detenerla se deciden después de que aparezca un problema.

• Asigna propietario, finalidad, fecha de revisión y comportamiento por defecto.
• Prueba las rutas activa e inactiva y las transiciones relevantes entre ambas.
• Registra cambios de configuración y limita quién puede realizarlos en producción.
• Define métricas de avance y una condición objetiva para detener la activación.

Comprueba qué significa realmente desactivar

Apagar una función impide su uso futuro, pero no deshace necesariamente correos enviados, datos transformados o tareas ya en curso. Si introduce un formato nuevo, la versión anterior debe poder convivir con él o disponer de una estrategia específica. Revisa estos efectos antes del lanzamiento. La posibilidad de desactivar rápidamente es útil, pero no elimina la necesidad de una migración compatible ni de un procedimiento para corregir consecuencias persistentes.

Controla combinaciones y evita banderas anidadas

Cada condición adicional amplía el espacio de comportamientos posibles. No todas las combinaciones merecen una prueba completa, pero las válidas y relevantes deben estar identificadas. Si varias banderas siempre cambian juntas, quizá representen una sola decisión. Si unas dependen de otras, documenta y simplifica esa relación. El código que acumula caminos antiguos durante meses resulta difícil de mantener y aumenta el riesgo de que una corrección solo se aplique a una de las rutas.

Incluye el estado relevante de las banderas en la información de diagnóstico sin exponer datos personales. Esto facilita entender por qué dos usuarios observan resultados diferentes con la misma versión de software. La documentación de Azure App Configuration describe la separación entre despliegue y disponibilidad como fundamento de la gestión de funcionalidades. La idea es aplicable con distintas herramientas; el equipo debe comprobar las garantías concretas de la que utilice, especialmente consistencia y permisos.

Retira la bandera cuando termine su trabajo

Tras estabilizar la función, elimina el camino antiguo, las pruebas que ya no corresponden y la configuración temporal mediante una tarea planificada. Conserva el historial de la decisión donde proceda. Revisar banderas vencidas en cada ciclo evita que una medida de seguridad de lanzamiento se convierta en deuda permanente. El objetivo es entregar cambios con un control proporcional y volver después a una base de código sencilla, comprensible y preparada para la siguiente evolución.