Deploy y release son eventos separados. El código entra en producción escondido detrás de una feature flag, y el release sucede después, para el público elegido, con un toggle. El equipo hace merge de código oscuro al trunk todos los días; producción recibe todo y el cliente no ve nada. El rollback se convierte en un cambio de configuración de segundos, sin revert de commit ni ventana de mantenimiento.

Cada tipo de flag tiene su ciclo de vida

Flags mezcladas en una sola pila se vuelven dígitos muertos en el config. Dale ciclo de vida propio a cada categoría: release flags viven días y mueren tras el 100% del rollout; kill switches (ops flags) quedan meses vigilando dependencias inestables; permissioning flags persisten como entitlements de plan; experiment flags siguen el calendario estadístico del test A/B. Cada flag nace con owner registrado y fecha prevista de remoción.

¿Cómo funciona un rollout progresivo?

Rampa clásica: 1% interno, 5%, 25%, 50%, 100%. Entre cada escalón, el equipo observa dashboard de error rate y latencia durante 24 horas antes de liberar el siguiente. LaunchDarkly, Unleash y Flagsmith entregan rampa porcentual lista; un servicio de config casero la resuelve con hash consistente del ID del usuario, garantizando que la misma persona caiga siempre en el mismo grupo. Evaluar server-side cuando sea viable evita payload inflado que entrega el roadmap a un competidor curioso inspeccionando el bundle JS.

Kill switches en dependencias externas

Toda dependencia externa arriesgada gana flag. ¿El proveedor de pagos cayó? Toggle al procesador fallback en segundos, sin deploy emergencial de viernes por la noche. Búsqueda, recomendaciones y cualquier llamada con camino alternativo aceptable merecen el mismo tratamiento. Prueba cada kill switch cada trimestre; la flag que nunca pasó por un apagado puede fallar justo el día del incidente.

Controlando la deuda técnica de flags

  • El CI marca branch de código de flag con edad mayor a la acordada (30, 60 días) y falla el build
  • Registro obligatorio de owner y expiry date en la creación de cada flag
  • La limpieza de flags obsoletas entra en el ritual de la sprint con ítem fijo en el board

La matriz de tests explota con combinaciones: N flags simultáneas generan 2^N caminos. Cubre el camino default-off y el default-on de cada flag y muestrea combinaciones críticas; cobertura total es inviable arriba de cinco flags al mismo tiempo. El bootstrap de las flags en la carga de la página garantiza consistencia en SSR, sin flash entre render del servidor e hidratación.