Feature Flags en PHP: la magia de activar y desactivar funciones sin desplegar
\n\nImagine: ha escrito una nueva función — un sistema de recomendaciones súper increíble. Todo está probado en su máquina local, pero tan pronto como el código llega a producción, comienza el infierno. Los usuarios están furiosos, la conversión cae, y usted está deshaciendo commits frenéticamente. ¿Le suena familiar?
\n\nAhora imagine otro escenario. Usted despliega la misma función, pero está desactivada por defecto. La activa para el 5% de los usuarios, observa las métricas, la despliega gradualmente. Si algo sale mal — simplemente la desactiva con un clic. Sin despliegue. Sin estrés. Eso es la magia de los Feature Flags (también conocidos como feature toggles, banderas de funciones).
\n\nEn este artículo en PythonLib, analizaremos cómo implementar feature flags en PHP desde cero. No solo aprenderá la teoría, sino que también obtendrá fragmentos de código listos que puede usar ahora mismo.
\n\n¿Qué son los Feature Flags y por qué los necesita un desarrollador PHP?
\n\nUn Feature Flag (bandera de función) es un interruptor de software que permite activar o desactivar la funcionalidad de una aplicación sin cambiar el código ni realizar un nuevo despliegue. En pocas palabras: escribe el código una vez y decide si mostrarlo al usuario o no, sobre la marcha.
\n\nLas 3 principales razones para usar banderas de funciones en PHP:
\n- \n
- Despliegue seguro: puede lanzar código a cualquier hora del día. Si algo se rompe — simplemente desactiva la bandera. \n
- Pruebas A/B: muestre diferentes versiones de la interfaz a diferentes segmentos de usuarios y compare métricas. \n
- Canary releases (lanzamientos canarios): despliegue una nueva función primero al 1% de la audiencia, luego al 10%, luego al 100%. \n
«Los Feature Flags son como un interruptor de luz. Puede encenderlo para toda la habitación, o solo para una esquina. Y no necesita recablear cada vez».\n\n
Implementación más simple de Feature Flags en PHP
\n\nComencemos con la opción más básica pero funcional. Supongamos que tenemos un archivo config.php donde se almacenan todas las banderas:
<?php\n// config.php\nreturn [\n 'features' => [\n 'new_checkout' => false,\n 'dark_mode' => true,\n 'search_v2' => false,\n ],\n];\n\n\nY ahora una clase envoltorio simple para verificar las banderas:
\n\n<?php\nclass FeatureFlagManager\n{\n private array $features;\n\n public function __construct(array $config)\n {\n $this->features = $config['features'] ?? [];\n }\n\n public function isEnabled(string $flag): bool\n {\n return $this->features[$flag] ?? false;\n }\n}\n\n// Uso:\n$manager = new FeatureFlagManager(require 'config.php');\n\nif ($manager->isEnabled('dark_mode')) {\n echo '<link rel="stylesheet" href="dark.css">';\n}\n\n\nLa desventaja de este enfoque es obvia: para cambiar una bandera, necesita modificar la configuración y redesplegar la aplicación. Esto no es mejor que hacer commit del código. Necesitamos una gestión dinámica.
\n\nFeature Flags dinámicos con almacenamiento en BD
\n\nEl patrón más común es almacenar los estados de las banderas en una base de datos o Redis. Así, se pueden cambiar a través de un panel de administración sin reiniciar la aplicación.
\n\nEstructura de tabla MySQL
\n\nCREATE TABLE feature_flags (\n id INT AUTO_INCREMENT PRIMARY KEY,\n flag_name VARCHAR(100) UNIQUE NOT NULL,\n is_enabled TINYINT(1) DEFAULT 0,\n description TEXT,\n created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,\n updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP\n);\n\n\nClase para trabajar con la BD
\n\n<?php\nclass DbFeatureFlags\n{\n private PDO $pdo;\n private array $cache = [];\n\n public function __construct(PDO $pdo)\n {\n $this->pdo = $pdo;\n }\n\n public function isEnabled(string $fla