Feature flags y desarrollo trunk-based

La mayoría de los equipos que tienen dificultades para entregar no son lentos porque sus ingenieros sean lentos. Son lentos porque sus ramas viven durante semanas, sus fusiones son aterradoras y cada publicación es un evento de gran impacto que alguien tiene que vigilar a las 2 de la madrugada. El desarrollo trunk-based y los feature flags atacan ese problema por dos lados: mantener el código integrado de forma continua y separar el momento en que despliegas del momento en que activas una funcionalidad.

Bien ejecutada, esta combinación es el motor silencioso detrás de los equipos que publican muchas veces al día con una guardia tranquila. Ejecutada sin cuidado, convierte tu base de código en un laberinto de interruptores obsoletos que nadie se atreve a borrar. Esta guía aborda ambos lados con honestidad.

Desplegar no es publicar

La idea más útil aquí es que desplegar código y publicar una funcionalidad son dos eventos distintos, y deberías poder hacer uno sin el otro.

En el modelo antiguo están soldados. El código llega a producción y, en ese instante, los usuarios ven el nuevo comportamiento. Ese acoplamiento es lo que hace que las publicaciones den miedo, porque la única forma de probar en un entorno real es exponer a todos a la vez, y la única forma de deshacer una mala publicación es volver a desplegar.

Separa ambas cosas y el miedo se disipa. El código se envía a producción a oscuras, envuelto en un flag que está apagado. Permanece ahí, ejercitado por tu conjunto de pruebas y tus comprobaciones de salud, sin tocar nada que un usuario pueda ver. Cuando estás listo, activas el flag para el uno por ciento del tráfico, observas tus métricas y luego subes a diez, cincuenta y cien. Si algo parece ir mal, lo desactivas en segundos sin desplegar. La publicación se convierte en una decisión en tiempo de ejecución tomada por una persona que vigila los paneles, no en un efecto secundario mecánico de un push.

Qué significa realmente el desarrollo trunk-based

El desarrollo trunk-based es un modelo de ramificación en el que todos hacen commit a una única rama compartida, el tronco, al menos una vez al día. Las ramas, si es que existen, viven durante horas y se fusionan el mismo día.

El objetivo no es ser dogmático con las ramas. El objetivo es mantener la distancia entre el trabajo de cualquier desarrollador y la línea principal compartida lo más corta posible, porque en esa distancia es donde el dolor de la integración se acumula.

Contrasta esto con las ramas de funcionalidad de larga vida. Una rama que sobrevive dos semanas se aleja en silencio del tronco. Para cuando la fusionas, estás reconciliando la divergencia acumulada de todo el equipo, y cuanto más grande sea la fusión, mayor será la probabilidad de que algo se rompa. El desarrollo trunk-based se niega a dejar que esa deuda se acumule. Integras pequeño, integras a menudo y cada integración es aburrida.

La objeción evidente es: ¿cómo fusiono el código de una funcionalidad que solo está a medias sin romper producción? Ese es exactamente el hueco que llenan los feature flags.

Dónde encajan los feature flags

Un feature flag es un condicional en tu código que decide en tiempo de ejecución si un comportamiento está activo. En su forma más simple es una sola línea: si el flag está encendido, ejecuta el camino nuevo; de lo contrario, ejecuta el viejo. Esa diminuta indirección es lo que te permite fusionar trabajo incompleto al tronco de forma segura, porque el camino nuevo permanece a oscuras hasta que decides encenderlo.

No todos los flags son iguales, y tratarlos como si fueran una sola cosa es un error común. Tienen vidas útiles distintas y dueños distintos.

Los cuatro tipos de flags

• Los flags de publicación ocultan el trabajo en curso para que pueda fusionarse antes de terminarse. Son de vida corta por diseño y deberían borrarse en el momento en que una funcionalidad se despliega por completo. Este es el flag que hace posible el desarrollo trunk-based.
• Los flags operativos son interruptores de apagado para subsistemas arriesgados: un motor de recomendaciones pesado, una integración de terceros inestable, una nueva capa de caché. Son de vida larga a propósito, porque quieres la capacidad de aliviar carga o desactivar una dependencia durante un incidente sin desplegar.
• Los flags de experimentación impulsan las pruebas A/B. Dirigen cohortes de usuarios a distintas variantes y permanecen en su sitio durante la vida del experimento, y luego se limpian cuando se elige un ganador.
• Los flags de permiso restringen funcionalidades por plan, rol o cuenta, por ejemplo una exportación solo para empresas. Son de hecho permanentes y pertenecen más a tu lógica de derechos que a tu pipeline de entrega.

Confundir estas categorías es donde los sistemas de flags se descarrilan. Un flag de publicación tratado como un flag de permiso nunca se borra, y seis meses después nadie recuerda si es seguro eliminarlo.

Un flujo de trabajo que se sostiene en 2026

Aquí tienes un ciclo concreto que usamos y recomendamos para equipos que migran a la entrega continua. Da por supuesto un conjunto de pruebas sólido y un verdadero servicio de flags en lugar de variables de entorno dispersas.

1. Corta el trabajo en finas rebanadas verticales. Divide la funcionalidad en piezas lo bastante pequeñas para fusionarse en un día, cada una un camino completo a través de la pila aunque al principio solo sirva a usuarios internos.
2. Envuelve el camino nuevo en un flag de publicación, apagado por defecto. El primer commit introduce el flag. Todo lo que viene después modifica código que ya está a oscuras en producción.
3. Fusiona al tronco a diario detrás del flag. Tus cambios llegan a producción de forma continua, ejercitados por CI y por las pruebas de integración, pero invisibles para los usuarios porque el flag está apagado.
4. Activa el flag primero de forma interna. Habilítalo para tu propio equipo y las cuentas del personal. Prueba lo real en el entorno real antes de que ningún cliente lo vea.
5. Escala con un despliegue por porcentaje. Pasa al uno por ciento del tráfico, luego a una cohorte más amplia, vigilando las tasas de error, la latencia y la métrica de negocio que la funcionalidad debe mover.
6. Vigila las métricas de guardarraíl en cada paso. Ata el despliegue a alertas. Si los presupuestos de error se consumen o una métrica clave retrocede, tienes una señal para pausar o revertir antes de que la mayoría de los usuarios se vean afectados.
7. Revierte apagando, no desplegando. Si algo se rompe, apaga el flag. El arreglo es instantáneo y sin culpas, y depuras con calma con el código todavía a salvo en el tronco.
8. Retira el flag una vez desplegado por completo. Después de que una funcionalidad esté al cien por cien y estable, borra el flag y la rama de código muerta en el mismo sprint. Este paso no es opcional.

Ese último paso es donde la mayoría de los equipos fallan, así que merece su propia disciplina.

Higiene de flags: saldar la deuda de flags

Cada flag de publicación es una pequeña deuda. Cada uno añade una ramificación en tu código, un estado que tus pruebas deben cubrir y una línea de carga cognitiva para la siguiente persona que lea el archivo. Un puñado está bien. Varios cientos de interruptores obsoletos son una segunda base de código invisible que nadie entiende y que todos temen tocar.

Mantén la deuda baja con unos pocos hábitos:

• Da a cada flag de publicación una fecha de vencimiento y un dueño en el momento de crearlo. Un flag sin dueño es un flag que nadie eliminará jamás.
• Haz seguimiento de la antigüedad de los flags y trata cualquiera que pase su vencimiento como un bug en tu backlog, no como una limpieza deseable.
• Borra el código, no solo el interruptor. Cuando quitas un flag, elimina la rama perdedora para que el camino ganador se convierta en el único camino.
• Limita el número de flags de publicación activos por servicio. Un límite estricto obliga a limpiar antes de que se acumule trabajo nuevo.
• Audita los flags de permiso y operativos por separado, ya que esos están pensados para vivir mucho tiempo y no deberían arrastrarse en la limpieza de flags de publicación.

Según nuestra experiencia, los equipos que se mantienen rápidos no son los que añaden flags más deprisa. Son los que los quitan igual de deprisa.

Compensaciones y modos de fallo

Este modelo no es gratis, y fingir lo contrario prepara a los equipos para quemarse.

• Las combinaciones de prueba explotan. Con muchos flags, el número de estados posibles crece rápido. No puedes probar cada combinación, así que prueba los caminos que importan: el estado actual de producción y los valores encendido y apagado de cada flag por separado.
• La evaluación de flags debe ser rápida y a prueba de fallos. Tu aplicación lee flags en el camino crítico, así que no se puede permitir que un servicio de flags lento o no disponible tumbe las solicitudes. Cachea los valores de los flags localmente y define un valor por defecto sensato para cuando el servicio sea inalcanzable.
• Los flags son una superficie de seguridad. Un flag de permiso que restringe una funcionalidad de pago es una decisión de control de acceso. Evalúalo en el servidor, nunca confíes en un valor de flag enviado desde el cliente y registra los cambios en los flags sensibles.
• El desarrollo trunk-based exige pruebas reales. Todo el modelo se apoya en un tronco que siempre es publicable. Sin pruebas automatizadas rápidas y fiables y sin integración continua, fusionar al tronco a diario solo propaga las roturas más rápido.

Estas son las mismas disciplinas que aparecen siempre que descompones un sistema para una entrega independiente. Si además estás sopesando hasta dónde dividir tu arquitectura, nuestra guía sobre pasar del monolito a los microservicios cubre las señales organizativas que hacen que el despliegue independiente valga su coste, y la mecánica de flags de aquí es cómo entregas esos servicios de forma segura una vez que los tienes.

Los flags también viajan a lo largo de las fronteras de tu API, así que los contratos que expones importan. Cuando un cambio bajo flag altera la forma de una respuesta o el comportamiento de un endpoint, los principios de nuestro artículo sobre diseñar APIs que los desarrolladores adoran te evitan entregar un cambio disruptivo detrás de un interruptor de apariencia inocente.

Cómo puede ayudar Innovation T

El desarrollo trunk-based y los feature flags son menos la compra de una herramienta y más un cambio en cómo trabaja un equipo: fusiones pequeñas, integración continua, despliegue progresivo y limpieza implacable. Llegar ahí suele significar reforzar el conjunto de pruebas, endurecer el pipeline de entrega y elegir un enfoque de flags que se ajuste a tu escala en lugar del nombre más grande del mercado.

En Innovation T, ese es exactamente el tipo de trabajo de ingeniería que hacemos. Ayudamos a los equipos a pasar de las ramas de larga vida y las publicaciones temidas a un flujo tranquilo y continuo: configurar flujos de trabajo trunk-based, cablear los feature flags a un pipeline de CI y CD, definir manuales de despliegue y reversión y construir la higiene de flags que mantiene la base de código limpia un año después. Explora nuestros servicios de ingeniería de software y cloud, o ponte en contacto para hablar de cómo entrega tu equipo hoy y dónde vive realmente la fricción.