Una feature flag separa el despliegue del código de la activación del comportamiento. En una automatización, permite publicar una nueva sincronización de facturas o regla de conciliación apagada, validarla con un grupo controlado y ampliar el uso mientras se observan los resultados. La flag no sustituye pruebas ni rollback: añade ramas en runtime, riesgo de configuración y un control operativo que necesita responsable.
| Propósito | Duración habitual | Control que definir |
|---|---|---|
| Ocultar una función incompleta | Corta, hasta su lanzamiento | Aprobación y fecha de limpieza |
| Kill switch operativo | Puede ser duradera | Quién la apaga, alerta y condición de recuperación |
| Experimento o cohorte | Hasta obtener evidencia suficiente | Asignación estable y métricas de éxito |
| Permiso o entitlement | Política de acceso permanente | Fuente oficial de autorización, no solo la interfaz |
No reutilices una flag booleana para propósitos distintos. Nombra el comportamiento, asigna responsable y revisión, y define explícitamente el estado apagado. Ante riesgo, debe conservar el comportamiento previo o detenerse con seguridad; nunca saltarse autorización, validación o auditoría.
Empieza por organización, cuenta de integración o entidad de prueba antes que por registros individuales. La asignación determinista evita que un retry cambie de comportamiento para el mismo cliente. No incluyas correos u otros datos personales en el contexto de evaluación si basta con una clave opaca estable. Revisa cómo el proveedor procesa ese contexto y su telemetría.
En trabajos por lotes, decide si evalúas la flag por tarea, lote de cliente o elemento. Un cambio durante la ejecución puede dividir una operación lógica entre dos caminos. Registra la variante junto al ID de correlación para facilitar el diagnóstico posterior.
Si no está disponible la configuración remota, ¿el job sigue con el camino anterior, pausa o falla de forma cerrada? Depende del efecto y del riesgo. Una caché con antigüedad limitada puede ayudar, pero no supongas que un kill switch remoto funciona durante una partición de red sin probarlo.
Mide evaluaciones, variante, versión y resultados sin registrar datos personales de segmentación. Compara errores, duplicados, diferencias de conciliación, latencia y tickets entre cohortes. Define el umbral de rollback y una forma visible para que operaciones desactive el camino. Un interruptor de emergencia no debería exigir un nuevo despliegue.
Prueba la configuración prevista para producción, el fallback y la flag modificada de forma aislada. No hace falta probar todas las combinaciones históricas, pero sí las interacciones dentro del mismo flujo. Elimina las flags temporales al terminar: las ramas obsoletas ocultan comportamiento y multiplican estados de prueba. Mantén pocos kill switches duraderos, documentados y revisados.
Las feature flags hacen reversible el rollout cuando segmentación, valores seguros, métricas y control operativo se diseñan juntos. Amplía la exposición gradualmente, mide invariantes, define qué pasa si falla el proveedor y asigna un responsable. Sin fecha de retirada, la flag se convierte en un misterio de producción.