Feature Toggle — fundamentos, tipos de interruptores y aplicación
Feature Toggle es un mecanismo en tiempo de ejecución para activar y desactivar funcionalidades de la aplicación, permitiendo a los desarrolladores gestionar la disponibilidad de funciones sin cambiar código ni redesplegar. A diferencia de la compilación condicional (ifdef), el toggle funciona a nivel de runtime y puede cambiar dinámicamente. Según Martin Fowler (2024), los feature toggles son un elemento clave del trunk-based development y la entrega continua. Feature toggle brinda a los equipos flexibilidad en la gestión de lanzamientos y experimentos.
Puntos clave
- Feature Toggle — un interruptor dinámico que controla el comportamiento de la aplicación mediante configuración
- Tipos principales: business toggles, release toggles, experiment toggles e infrastructure toggles
- Feature Toggle vs Flag — toggle suele referirse a interruptores binarios simples, flag — a plataformas completas
- Integración CI/CD permite verificar y probar automáticamente los toggles en cada etapa del pipeline
- Problema principal — acumulación de stale toggles, que deben auditarse y eliminarse regularmente
Qué es un Feature Toggle
Feature Toggle es una técnica en la que el código de una nueva funcionalidad se envuelve en una construcción condicional que verifica el valor de un parámetro de configuración. Si el parámetro es verdadero — la nueva funcionalidad está activa, si es falso — se ejecuta el código antiguo. La diferencia clave con un feature flag es que un toggle es un interruptor binario que funciona según el principio de encendido/apagado, sin reglas complejas de segmentación ni distribución de tráfico.
Definición y principio de funcionamiento
Un feature toggle se implementa como una simple construcción if alrededor de una nueva funcionalidad. El valor del toggle se almacena en la configuración de la aplicación — variables de entorno, un archivo JSON o una base de datos. Cuando la aplicación se inicia, carga la configuración y la utiliza para tomar decisiones sobre la visibilidad de las funciones. En el caso más simple, cambiar el valor de un toggle requiere reiniciar la aplicación, pero en sistemas de producción los toggles suelen admitir recarga en caliente a través de un servidor de configuración externo o API.
Ejemplo de toggle simple
Veamos una implementación de feature toggle en JavaScript (Node.js). El toggle se almacena en un archivo JSON de configuración y se carga al iniciar el servidor. El middleware verifica el valor del toggle antes de enrutar la solicitud al controlador nuevo o antiguo. Esta implementación permite agregar nueva funcionalidad a la rama principal del código sin afectar la versión actual de la API.
js
const config = require("./config.json");
const toggles = {
get(name) {
return config.features[name] ?? false;
},
isEnabled(name, context) {
const toggle = config.features[name];
if (!toggle) return false;
if (toggle.enabled === true) return true;
if (toggle.percentage && context.userId) {
return hashCode(context.userId) % 100 < toggle.percentage;
}
return false;
}
};
const app = express();
app.use("/api/checkout", (req, res, next) => {
if (toggles.isEnabled("new_checkout", req)) {
return newCheckoutHandler(req, res);
}
return legacyCheckoutHandler(req, res);
});Tipos de Feature Toggles
Pete Hodgson de ThoughtWorks identifica tres tipos principales de feature toggles, clasificándolos por su vida útil y propósito. Identificar correctamente el tipo de toggle ayuda a elegir el mecanismo de almacenamiento y el proceso de gestión adecuados. Veamos cada tipo en el contexto del desarrollo móvil.
Business y Release Toggles
Los Business toggles son los interruptores de mayor duración. Gestionan reglas de negocio disponibles solo para ciertas categorías de usuarios (funciones premium, particularidades regionales). Estos toggles pueden vivir durante años y suelen tener una lógica más compleja que el encendido/apagado binario. Los Release toggles son interruptores temporales para ocultar funcionalidades incompletas. Su ciclo de vida va desde unos pocos días hasta unas pocas semanas. Una vez que la funcionalidad está completa, el release toggle se elimina del código. Estos toggles son la base del trunk-based development, permitiendo a los desarrolladores hacer commit en la rama principal sin esperar a que toda la funcionalidad esté completa.
Experiment e Infrastructure Toggles
Los Experiment toggles se utilizan para pruebas A/B y despliegue gradual. A diferencia de los release toggles, los experiment toggles admiten distribución porcentual de usuarios e integración con sistemas de analítica. Pueden vivir más que los release toggles (hasta varios meses), pero también deben eliminarse después de que el experimento concluya. Los Infrastructure toggles son interruptores para gestionar cambios de infraestructura: migración de bases de datos, cambio a un nuevo proveedor de API, modificación de algoritmos de caché. Estos toggles requieren especial atención a las pruebas, ya que su activación afecta la estabilidad de todo el servicio.
| Tipo de toggle | Duración | Audiencia | Ejemplo |
|---|---|---|---|
| Business | Meses-años | Por roles/regiones | Funciones premium |
| Release | Días-semanas | Desarrolladores/QA | Pantalla incompleta |
| Experiment | Semanas-meses | % de usuarios | Prueba A/B de interfaz |
| Infrastructure | Días-semanas | Interna | Migración de BD |
Feature Toggle vs Feature Flag
Aunque los términos “feature toggle” y “feature flag” se usan a menudo como intercambiables, existen diferencias conceptuales entre ellos. Comprender estas diferencias ayuda a elegir la herramienta adecuada para una tarea específica y evitar confusiones en el equipo. Veamos las diferencias clave y los casos de uso de cada enfoque.
Diferencias en el enfoque
Feature toggle es principalmente un mecanismo técnico: un interruptor binario incrustado en el código de la aplicación. El toggle se gestiona a través de la configuración y no requiere infraestructura externa. Feature flag es un concepto más amplio que incluye una plataforma de gestión: interfaz de usuario para configuración, SDK para integración, monitoreo de uso, analítica y auditoría. Los flags admiten reglas complejas de segmentación (por región, versión, dispositivo), experimentos A/B y eliminación automática. Se podría decir que el feature flag es la evolución del feature toggle: los equipos comienzan con interruptores de configuración simples y migran a una plataforma especializada a medida que crecen.
Cuándo un toggle es suficiente
Para equipos pequeños y proyectos con un servicio único o monolito, los toggles de configuración simples son perfectamente suficientes. Si tienes 5–10 desarrolladores y 1–2 toggles activos a la vez, una plataforma externa sería excesiva. Las plataformas de feature flags (LaunchDarkly, Unleash) se vuelven necesarias cuando el número de flags activos supera 20–30, el equipo tiene 20+ desarrolladores, o se necesita control de acceso detallado para diferentes segmentos de usuarios. Para aplicaciones móviles, donde las actualizaciones del cliente llevan días, las plataformas de feature flags brindan una ventaja adicional — la capacidad de cambiar el comportamiento de la aplicación sin publicar una nueva versión.
Herramientas de gestión
La elección de una herramienta de gestión de feature toggles depende del tamaño del equipo, la pila tecnológica y los requisitos de seguridad. Veamos las opciones desde archivos de configuración simples hasta plataformas de gestión empresarial, incluyendo alternativas de código abierto.
Integración con CI/CD
Los feature toggles deben ser ciudadanos de primera clase del pipeline CI/CD. En la etapa de compilación, el pipeline verifica que todos los release toggles programados para eliminación en el sprint actual estén realmente eliminados del código. En la etapa de pruebas, se ejecutan pruebas matriciales con diferentes combinaciones de toggles. En la etapa de despliegue, el sistema sincroniza automáticamente la configuración de toggles con el entorno de producción. La integración con PagerDuty u Opsgenie permite crear alertas cuando se detectan stale toggles o cuando se supera el número permitido de toggles activos.
Soluciones populares
Para escenarios simples, un archivo JSON de configuración en Git con revisión de código en los cambios es suficiente. Una opción más avanzada es Togglz (Java) o Gofeature (Go) — bibliotecas que agregan una interfaz de usuario mínima para la gestión de toggles. Para sistemas de producción, se recomienda Unleash (código abierto) con SDK para todos los lenguajes y soporte de estrategias de activación, o Flagsmith con pruebas A/B integradas. LaunchDarkly sigue siendo el estándar para proyectos empresariales con altos requisitos de auditoría y cumplimiento. Para aplicaciones móviles, todas las soluciones proporcionan SDK nativos con almacenamiento en caché y modo offline.
Deuda técnica y eliminación
Los feature toggles son una herramienta de doble filo. Sin disciplina de gestión, se convierten en deuda técnica que ralentiza el desarrollo y aumenta la complejidad del código. Según un estudio de CodeScene (2024), el 35–50% de las bases de código contienen stale toggles — interruptores que permanecen en el código después de completar el despliegue. Veamos estrategias para prevenir y eliminar dicha deuda.
Eliminación de toggles
El proceso de eliminación de un feature toggle consta de cuatro pasos. Primero: asegurarse de que el toggle esté activado para el 100% de la audiencia o desactivado para el 0% (dependiendo de qué rama de código deba permanecer). Segundo: eliminar todas las comprobaciones condicionales del toggle del código, dejando solo la rama que debe ser el comportamiento de producción. Tercero: eliminar la definición del toggle del sistema de almacenamiento (configuración, base de datos o plataforma). Cuarto: ejecutar pruebas para confirmar que la eliminación no rompió la funcionalidad. Cada toggle debe tener un propietario y una fecha de eliminación planificada, registrados al crear el interruptor.
Automatización de auditoría
La auditoría manual de toggles no es eficiente a escalas superiores a 50 interruptores. La automatización se basa en tres principios: verificación en CI (los stale toggles bloquean el merge), monitoreo (un panel que muestra la edad y el estado de cada toggle), alertas (notificar al propietario si un toggle no ha cambiado en N días). Las herramientas de análisis estático de código (SonarQube, plugin de ESLint) pueden detectar toggles que están siempre activados o siempre desactivados en el código — una señal clara de stale toggle. La comprobación final es la revisión de código, donde el revisor debe verificar que el nuevo toggle realmente sea necesario y que la rama de código antigua será eliminada.
go
package toggles
type Toggle struct {
Name string
Enabled bool
Owner string
CreatedAt time.Time
TTL time.Duration
}
type ToggleManager struct {
store map[string]*Toggle
}
func NewToggleManager() *ToggleManager {
return &ToggleManager{store: make(map[string]*Toggle)}
}
func (m *ToggleManager) IsEnabled(name string) bool {
t, ok := m.store[name]
if !ok {
return false
}
return t.Enabled
}
func (m *ToggleManager) GetStaleToggles() []string {
var stale []string
for name, t := range m.store {
if t.Enabled && time.Since(t.CreatedAt) > t.TTL {
stale = append(stale, name)
}
}
return stale
}Preguntas frecuentes
¿En qué se diferencia un feature toggle de un feature flag?
Los términos a menudo se usan indistintamente, pero técnicamente feature toggle es un interruptor binario en el código (una condición if que verifica un valor de configuración). Feature flag es un concepto más amplio que incluye una plataforma de gestión con interfaz de usuario, SDK, analítica y reglas complejas de segmentación. Un toggle no requiere infraestructura externa; un flag generalmente sí.
¿Con qué frecuencia deben eliminarse los toggles antiguos?
Los release toggles deben eliminarse dentro de 1–2 semanas después de completar el despliegue. Los experiment toggles — inmediatamente después de que concluya la prueba A/B. Los business toggles requieren auditoría regular (trimestral). Se recomienda configurar una verificación en CI que bloquee el merge si un PR agrega un nuevo toggle sin una tarea de eliminación en el task tracker.
¿Se pueden usar toggles para aplicaciones móviles?
Sí, los feature toggles se utilizan activamente en el desarrollo móvil. La herramienta principal es Firebase Remote Config, que permite gestionar dinámicamente los interruptores sin publicar una nueva versión de la aplicación. Alternativas: SDK de LaunchDarkly para iOS/Android, SDK de Unleash, un servidor de toggle personalizado con API REST. Es importante implementar el almacenamiento en caché de valores para el modo offline.
¿Cómo probar código con feature toggles?
El método principal es pruebas matriciales: ejecutar todas las pruebas con el toggle activado y desactivado. Para N toggles, las pruebas matriciales completas requieren 2^n ejecuciones, por lo que en la práctica se seleccionan combinaciones críticas. Las pruebas unitarias deben simular el valor del toggle. Las pruebas de integración verifican escenarios específicos. Se agrega un paso en CI que ejecuta pruebas con una combinación aleatoria de toggles para detectar interacciones inesperadas.
¿Cuáles son los riesgos de los feature toggles?
Riesgos principales: 1) stale toggles — el código con ambas ramas (activado/desactivado) se vuelve complejo y difícil de mantener; 2) complejidad combinatoria de pruebas — cada toggle duplica el número de estados; 3) código muerto — la rama antigua permanece en el código después de que el toggle se activa permanentemente; 4) seguridad — los interruptores que controlan el acceso crean vulnerabilidades si se configuran incorrectamente. Todos los riesgos son manejables con disciplina y automatización.
Resumen
- Feature Toggle — un interruptor binario de funcionalidad controlado mediante configuración de la aplicación
- Tipos principales: business (meses-años), release (días-semanas), experiment (semanas-meses), infrastructure (días-semanas)
- Feature Toggle vs Flag — toggle es más simple (condición if + configuración), flag incluye una plataforma de gestión completa
- Integración CI/CD obligatoria: verificación de stale toggles, pruebas matriciales, sincronización de configuración
- Stale toggles — el principal riesgo: 35–50% de las bases de código contienen interruptores no utilizados
- Eliminación de toggle requiere un proceso: confirmar estado, eliminar código, eliminar configuración, ejecutar pruebas
- Automatización de auditoría mediante CI, paneles y análisis estático de código previene la acumulación de deuda técnica
Desarrollaremos una aplicación móvil llave en mano
IT Sectr crea aplicaciones para iOS y Android para startups y empresas desde 2017. Le asesoraremos y le propondremos la mejor solución.
Lea también