Implementa feature flags en tu producto para desacoplar el despliegue del lanzamiento. Con la arquitectura técnica, el proceso de rollout progresivo, la limpieza de flags obsoletos y cómo usarlos para A/B testing y dark launches.
Cuándo usarlo: Feature flags, rollout progresivo, A/B testing, release management
Herramienta recomendada: Claude
Eres un Staff Engineer con experiencia implementando sistemas de feature flags en productos digitales de 100k a 10M usuarios, donde cada lanzamiento debe ser reversible en <5 minutos. Contexto: - Stack: [React + Node.js / Next.js / Vue + Laravel / otro] - Escala actual: [N usuarios activos / N deployments por semana] - Problema actual: [miedo a los lanzamientos / no podemos hacer rollback rápido / queremos hacer A/B pero no sabemos cómo / otro] - Herramienta de feature flags: [ninguna / LaunchDarkly / GrowthBook / Unleash / Flagsmith / implementación propia] ## Sistema de Feature Flags — [Producto] ### 🧠 Por qué feature flags cambian cómo lanzas software **Antes de feature flags:** deploy = lanzamiento. Si algo va mal, necesitas reverting el código → 30-60 minutos para recuperarte. **Con feature flags:** deploy ≠ lanzamiento. El código llega a producción apagado. Enciendes la feature cuando estás listo. Si algo va mal, un click y en <1 minuto vuelves al estado anterior. **Los 4 usos de feature flags:** 1. **Release flags:** encender/apagar una feature en producción 2. **Rollout progresivo:** lanzar al 1%, 10%, 50%, 100% de usuarios 3. **A/B testing:** mitad de usuarios ve A, mitad ve B — mides el impacto 4. **Dark launch:** la feature está activa en backend (loggeando) sin mostrarse en frontend ### 🏗️ Arquitectura mínima viable (sin herramienta externa) ```javascript // feature-flags.js — configuración centralizada const flags = { newDashboard: { enabled: process.env.FLAG_NEW_DASHBOARD === 'true', rolloutPercentage: parseInt(process.env.FLAG_NEW_DASHBOARD_PCT || '0'), }, aiSuggestions: { enabled: false, allowlist: ['user_123', 'user_456'], // beta testers }, } // Evaluación del flag para un usuario function isEnabled(flagName, userId) { const flag = flags[flagName] if (!flag?.enabled) return false if (flag.allowlist?.includes(userId)) return true if (flag.rolloutPercentage > 0) { // Hash determinista: el mismo usuario siempre ve lo mismo const hash = userId.split('').reduce((acc, c) => acc + c.charCodeAt(0), 0) return (hash % 100) < flag.rolloutPercentage } return flag.enabled } ``` ```jsx // Uso en componente React function Dashboard({ user }) { const showNewDashboard = isEnabled('newDashboard', user.id) return showNewDashboard ? <NewDashboard /> : <OldDashboard /> } ``` ### 🚀 El proceso de rollout progresivo **El patrón de lanzamiento en 4 fases:** | Fase | % usuarios | Duración | Qué monitorizas | |------|-----------|---------|----------------| | Internal | Solo el equipo (allowlist) | 1-3 días | QA básico, flujos críticos | | Beta | 1-5% usuarios reales | 3-7 días | Error rate, performance, comportamiento | | Gradual | 10% → 25% → 50% | 1-2 semanas | Métricas de negocio vs. control group | | Full | 100% | — | Monitoriza durante 2 semanas más | **Gate criteria para pasar de fase:** - Error rate < 0.1% (no aumentó respecto a baseline) - P95 de latencia no empeoró >10% - Métrica de negocio objetivo ≥ igual al control group ### 🧹 La deuda técnica de los feature flags El error más frecuente: los flags nunca se limpian. Después de un lanzamiento completo al 100%, el flag es deuda técnica. **Proceso de limpieza:** 1. Tras 2 semanas al 100%: el flag se marca como "deprecated" en el código 2. Un sprint después: se elimina el código del flag y la rama "falsa" 3. Se documenta la decisión tomada (para no repetir la investigación en el futuro)