Feature flags: el interruptor detrás de toda migración segura

Una feature flag es una condición que se evalúa en tiempo de ejecución en tu código y decide qué comportamiento se ejecuta, para que puedas cambiarlo sin volver a desplegar. En una migración, las feature flags son el interruptor que envía a los usuarios a la implementación antigua o a la nueva, lo que significa que una release defectuosa normalmente se puede deshacer cambiando un valor en lugar de esperar un nuevo despliegue.

Dependí de esto en avanzzada, donde lideré la migración completa de una plataforma que postula automáticamente a ofertas de empleo en nombre de sus usuarios. Migramos toda su arquitectura de un stack legado a uno nuevo mientras la gente la seguía usando todos los días. Esta guía cubre lo que me habría gustado saber antes de empezar.

¿Qué son las feature flags?

Una feature flag, también llamada feature toggle, es una verificación en tu código del tipo “si el nuevo checkout está activado, úsalo; si no, usa el anterior”. Lo importante es que la respuesta no vive en el código. Vive en un archivo de configuración, en una tabla de la base de datos o en un servicio de flags, así que cambiarla no requiere un nuevo despliegue.

Eso separa dos cosas que los equipos suelen tratar como una sola: desplegar y liberar. Puedes llevar código nuevo a producción desactivado, probarlo con usuarios internos y luego exponerlo de forma gradual.

Una flag se puede evaluar de distintas maneras:

• De forma global, para todos a la vez.
• Por usuario o por cuenta.
• Para un porcentaje del tráfico.
• Por entorno, como staging o producción.

¿Cómo hacen las feature flags que una migración sea reversible?

Sin flags, cada paso de una migración es una puerta de un solo sentido. Despliegas, miras los dashboards y, si algo se rompe, haces rollback volviendo a desplegar, lo cual es lento y estresante. Con una flag, el rollback es mover un interruptor.

Si es una base de código que acabo de heredar, las flags no son mi primer paso. En las primeras semanas de hacerme cargo de un sistema sigo un orden fijo: primero los accesos, luego el build, luego los caminos del dinero y luego los riesgos. Solo cuando puedo compilar y desplegar de forma confiable empiezo a agregar interruptores.

A partir de ahí, mi regla es poner el interruptor delante de todo antes de escribir código nuevo. La secuencia queda así:

1. Agrega la flag y envía a todos por el camino antiguo.
2. Construye el camino nuevo detrás de la flag, desactivado.
3. Cuando sea posible, ejecuta el camino nuevo en segundo plano y compara sus resultados con los del antiguo, mientras los usuarios siguen recibiendo el resultado antiguo.
4. Actívalo para los usuarios internos.
5. Actívalo para un grupo pequeño de usuarios reales y vigila los errores y las métricas de negocio.
6. Amplía el grupo paso a paso hasta que todos estén en el camino nuevo.
7. Conserva el camino antiguo durante una ventana de estabilidad y luego elimínalo.

Lo que las flags no pueden revertir

Una flag revierte qué código se ejecuta. No revierte los datos. Si el camino nuevo escribe en una base de datos nueva o cambia un esquema, volver a mover la flag deja al sistema antiguo sin esas escrituras, a menos que mantengas ambos sincronizados. Planifica esa parte por separado y ten el mayor cuidado en los caminos del dinero, como pagos, facturación y checkout. Como trabajé en el equipo de carrito y checkout de Total Wine & More, trato esos caminos con especial cautela: grupos pequeños, observación prolongada y una definición clara de qué significa “roto” antes de empezar.

¿Qué tipos de flags existen: release, operativas, experimento y permiso?

No todas las flags son iguales, y mezclarlas es lo que desordena los sistemas de flags. Una forma común de clasificarlas:

En las migraciones, las flags de release y las operativas hacen la mayor parte del trabajo. Las de release mueven el tráfico. Las operativas son el freno de emergencia. Las de experimento y de permiso importan menos, pero las de permiso son útiles para dejar que un cliente de confianza pruebe primero el camino nuevo.

La columna de vida útil importa. Las flags de release y de experimento deberían ser temporales. Las operativas y de permiso pueden quedarse, pero deberían estar marcadas como permanentes para que nadie se pregunte si se pueden borrar.

¿Conviene construir las feature flags o usar un servicio?

Ambas opciones son razonables. La respuesta correcta depende de quién necesita cambiar las flags y de cuántos sistemas las leen.

Cuándo basta con construirlo tú mismo

Para una sola aplicación y unas pocas flags, funciona una tabla en la base de datos o un archivo de configuración con una pequeña función auxiliar. Es barato y no suma un proveedor nuevo. Como regla general (estimación mía, no un estándar), esto se sostiene mientras solo los ingenieros cambien las flags y rara vez necesites liberaciones por porcentaje.

Cuándo un servicio se justifica

Considera un servicio cuando necesites:

• Liberaciones graduales por porcentaje y segmentación por atributos del usuario.
• Un registro de auditoría de quién cambió qué y cuándo.
• Que personas que no son ingenieros, como soporte o producto, cambien flags de forma segura.
• Que varios servicios lean las mismas flags de forma consistente.

Las opciones incluyen productos comerciales como LaunchDarkly y de código abierto como Unleash, Flagsmith y GrowthBook. Revisa los precios y modelos de hosting actuales en sus propios sitios, porque cambian.

Elijas lo que elijas, diséñalo para que falle de forma segura. En mis propios proyectos, si el almacén de flags no está disponible, el código recurre a un valor por defecto conocido, normalmente el camino antiguo. Mantén la evaluación rápida y guarda los valores en caché, para que una verificación de flag nunca sea lo que hace lenta o tumba tu aplicación.

¿Cómo evitar que las flags se conviertan en deuda técnica?

Cada flag crea al menos dos caminos de código, y cada camino extra hay que entenderlo, probarlo y, en algún momento, eliminarlo. Las flags que quedan olvidadas después de una liberación son una fuente común de código confuso y bugs inesperados.

Estos hábitos lo mantienen bajo control:

• Asigna a cada flag un responsable y una fecha de eliminación al crearla, no después.
• Crea la tarea de limpieza al mismo tiempo que la flag, para que la eliminación sea trabajo planificado. Yo abro ese ticket en el mismo pull request que agrega la flag.
• Nombra las flags según su propósito, no con una etiqueta vaga de proyecto.
• Evita anidar flags dentro de otras flags. Las combinaciones se multiplican rápido.
• Elimina el código antiguo, no solo la flag, una vez que el camino nuevo haya estado estable al 100% durante la ventana que elegiste.
• Revisa la lista con regularidad. Ordenar las flags por antigüedad muestra lo que quedó obsoleto.
• Prueba ambos estados en los caminos críticos, pero no intentes probar todas las combinaciones.

Trata la eliminación de flags como parte de la migración, no como una limpieza opcional. La migración no termina hasta que el camino antiguo y su flag desaparecen.

¿Cómo funcionan las feature flags con el patrón strangler fig?

El patrón strangler fig reemplaza un sistema en vivo pieza por pieza. Una capa de enrutamiento se ubica delante del sistema antiguo, y partes de la funcionalidad pasan al nuevo con el tiempo hasta que al sistema antiguo no le queda nada por hacer.

Las flags son el mecanismo de control de esa capa de enrutamiento. El router o proxy decide qué sistema atiende una ruta determinada, y una flag decide quién recibe la versión nueva de esa parte. Puedes mover un endpoint o una pantalla a la vez, enviar a un grupo pequeño por la versión nueva y ampliarlo a medida que crece la confianza.

Es el mismo principio que seguí en avanzzada. La plataforma siguió en vivo y los usuarios siguieron dependiendo de ella a diario, así que cada cambio tenía que ser lo bastante pequeño para vigilarlo y fácil de deshacer. Una reescritura big-bang no ofrece esa salida. Una reescritura además suele costar más y tardar más que una migración incremental, porque el sistema antiguo tiene que seguir funcionando en paralelo de todos modos.

¿Quieres una segunda opinión sobre tu migración?

Si estás planificando una migración y quieres validar cómo la liberarías y cómo harías el rollback, escribe a me@filipeeduardo.dev con el contexto. Con gusto comparamos notas y te digo qué revisaría primero.