Has terminado la característica. La solicitud de extracción está limpia. QA dice que parece bien. Y todavía no quieres enviarla a todos al mismo tiempo.
Es ese sentimiento el primero que indica que tu aplicación de React ha superado los simples despliegues. Una vez que un producto tiene usuarios reales, un lanzamiento deja de ser solo un evento técnico. Se convierte en una decisión de riesgo. Si la nueva interfaz de búsqueda rompe, si la variante de pago confunde a los usuarios, o si un paquete móvil envía code no puedes deshacerte rápidamente, necesitas más que if (process.env.NODE_ENV) y esperanza.
Es ahí donde las banderas de características de React comienzan a importar. No como una simple booleana en un componente, sino como una capa de control de lanzamiento que te permite enviar code por separado de exponerlo. En aplicaciones web, eso significa lanzamientos más seguros. En aplicaciones empaquetadas como Capacitor o Electron, importa aún más porque la velocidad de rollback está limitada por la revisión de la tienda, el retraso de instalación y ciclos de lanzamiento más lentos.
Contenido de la Tabla de Materiales
- Why Feature Flags Are Essential for Modern React Apps
- Diseñando Bandejas de Características en Tu Aplicación de React
- Implementación de estrategias de lanzamiento y retroceso
- Probando Observabilidad y Gestión de Deuda de Marcadores
- Protegiendo tus Marcadores y Automatizando con CI/CD
- Más allá de las Marcadores de Características para Capacitor y Aplicaciones Móviles
Why Feature Flags Are Essential for Modern React Apps
¡Lanzamiento el viernes por la tarde! La nueva interfaz de resumen de facturación ya está desplegada, el soporte tiene un checklist de lanzamiento abierto y un cliente empresarial todavía necesita el flujo antiguo hasta el lunes. En una aplicación web, eso ya es tenso. En una aplicación de React empaquetada que se envía a través de instaladores de escritorio o tiendas móviles, se vuelve peor porque el rollback puede tomar horas o días en lugar de minutos.
Las banderas de características dan a los equipos de React control sobre ese momento. Les permiten enviar la code, mantenerla dormida y decidir más tarde qué usuarios deben verla. Eso cambia el trabajo de lanzamiento de un evento todo o nada en una operación controlada.
El despliegue y el lanzamiento son trabajos diferentes
El despliegue responde, “¿La code está en producción?” El lanzamiento responde, “¿Quién puede ejecutar este comportamiento en este momento?”
Esta distinción importa una vez que una aplicación de React tenga tráfico real, múltiples entornos y características que toquen la recaudación, permisos o navegación. Los equipos pueden fusionar temprano, probar en producción con cohortes internos y ampliar el acceso solo después de que confíen en el comportamiento. En plataformas de lanzamiento más lentas, como aplicaciones de Capacitor, aplicaciones de Electron y ediciones de aplicaciones móviles revisadas por la tienda, ese control es aún más valioso porque el binario ya puede estar en manos de los usuarios antes de que la característica esté lista para todos.
Una bandera ayuda en tres situaciones que surgen constantemente:
- Despliegue controlado: exponer un nuevo camino a un pequeño grupo primero
- Experimentación: comparar variantes sin mantener despliegues separados
- Apagado rápido: desactivar una característica arriesgada sin esperar a una nueva compilación
Una regla simple funciona bien aquí. Si un problema de producción sería costoso revertir, envíe ese code detrás de una bandera.
Equipos nuevos con flags a menudo se detienen en la interfaz condicional. flag ? <NewUI /> : <OldUI /> es la parte visible, pero no es la parte interesante. Su valor fundamental es operativo. La configuración remota, el objetivo determinista y la capacidad de apagar rápidamente una característica son lo que hacen que las banderas sean útiles en producción. Si su aplicación de React también necesita ajustes de configuración de tiempo de ejecución para toda la aplicación, un plugin de configuración remota para aplicaciones Capacitor se ajusta al mismo modelo de control de versiones.
Las banderas dejan de ser útiles cuando nadie confía en ellas
Veo el mismo patrón de falla en los códigobases de frontend en crecimiento. Un equipo agrega banderas rápidamente, el desplazamiento de nombres entre entornos, los valores de fallback ocultan errores de configuración y nadie está seguro de si ‘activado’ significa activado globalmente, activado para personal, o activado solo en staging. En ese punto, el sistema de banderas comienza a crear riesgos en lugar de reducirlos.
La seguridad de tipo ayuda, pero no resuelve el problema entero. Los equipos todavía necesitan un registro claro, propiedad y una forma consistente de evaluar banderas a lo largo de la aplicación. De lo contrario, los componentes de React acaban haciendo suposiciones locales sobre el estado de lanzamiento y esas suposiciones se rompen durante lanzamientos o retrocesos parciales.
La diferencia es fácil de detectar:
| Uso de caso | Versión débil | Versión fuerte |
|---|---|---|
| botón de interfaz | Booleano local en el estado del componente | Bandera remota con reglas de propiedad y despliegue |
| Seguridad de lanzamiento | Revertir despliegue manual | Deshabilitar inmediato a través de configuración remota |
| Experimentación | Comparación de rama ad hoc | Asignación de cohorte estable y exposición medible |
El cambio de mentalidad importante es simple. Las banderas de características de React pertenecen a tu proceso de lanzamiento, no solo a tu JSX. Trátalas de esa manera, especialmente en aplicaciones donde enviar un nuevo paquete es lento, y se convierten en una de las pocas herramientas que reducen el radio de explosión cuando la producción se vuelve desordenada.
Diseñando Banderas de Características en Tu Aplicación de React
La decisión de arquitectura importa más que la primera bandera. Si conectas banderas directamente a componentes aleatorios, obtendrás lógica duplicada, parpadeo de carga y un código base donde nadie sabe qué fuente de verdad confiar.
Utiliza un proveedor de tiempo de ejecución, no condicionales dispersos
Para aplicaciones de React, la aproximación confiable es tratar banderas como datos de tiempo de ejecuciónLa guía para la banderización de React recomienda tres cosas: evaluar banderas en el servidor o en una caché local SDK, persistir la asignación de cohorte de manera determinista y renderizar el estado de interfaz final antes de la hidratación o utilizar protección contra parpadeo para que los usuarios no vean el valor por defecto incorrecto primero (Metodología de banderas de React).
Eso cambia dónde tu code debería vivir. Coloca la carga de banderas cerca de la raíz de la aplicación. Facilita el consumo. Evita cargar banderas dentro de componentes hoja.
Una forma práctica es esta:
- Carga o hidrata banderas antes de que se renderice el árbol principal.
- Exponelas a través de un proveedor.
- Lee las a través de un hook o un patrón de envoltura.
- Mantenga la lógica de evaluación fuera de los componentes presentacionales.
Si necesita una capa de configuración remota para ajustes de aplicación y banderas, una herramienta como Capacitor plugin de configuración remota se adapta naturalmente a este patrón en aplicaciones híbridas de React.
Patrón uno con React Context y una función personalizada
Este es el patrón por defecto que recomiendo generalmente. Es explícito, probable y fácil de migrar más tarde si cambia de proveedores.
import React, { createContext, useContext, useMemo } from 'react';
type FlagValue = boolean | 'control' | 'variant-a' | 'variant-b';
type Flags = {
newCheckout: boolean;
checkoutExperiment: FlagValue;
deleteTaskEnabled: boolean;
};
const defaultFlags: Flags = {
newCheckout: false,
checkoutExperiment: 'control',
deleteTaskEnabled: false,
};
const FeatureFlagContext = createContext<Flags>(defaultFlags);
export function FeatureFlagProvider({
flags,
children,
}: {
flags: Flags;
children: React.ReactNode;
}) {
const value = useMemo(() => flags, [flags]);
return (
<FeatureFlagContext.Provider value={value}>
{children}
</FeatureFlagContext.Provider>
);
}
export function useFeatureFlag<K extends keyof Flags>(key: K): Flags[K] {
return useContext(FeatureFlagContext)[key];
}El uso sigue siendo aburrido, lo que es exactamente lo que deseas:
function DeleteTaskButton() {
const enabled = useFeatureFlag('deleteTaskEnabled');
if (!enabled) return null;
return <button>Delete task</button>;
}Este patrón funciona bien porque los componentes solo preguntan por una respuesta final. No se preocupan por cómo se calculó la respuesta.
Patrón dos con un componente de alto nivel
Un componente de alto nivel Es útil cuando deseas bloquear una pantalla completa, un elemento de ruta o un componente de clase heredado sin agregar llamadas a hook en todos lados.
import React from 'react';
import { useFeatureFlag } from './FeatureFlagProvider';
export function withFeatureFlag<P>(
flagKey: 'newCheckout' | 'deleteTaskEnabled',
Fallback?: React.ComponentType<P>
) {
return function wrap(Component: React.ComponentType<P>) {
return function FeatureFlaggedComponent(props: P) {
const enabled = useFeatureFlag(flagKey);
if (!enabled) {
return Fallback ? <Fallback {...props} /> : null;
}
return <Component {...props} />;
};
};
}Uso:
const CheckoutPage = () => <div>New checkout</div>;
const LegacyCheckoutPage = () => <div>Legacy checkout</div>;
export default withFeatureFlag('newCheckout', LegacyCheckoutPage)(CheckoutPage);El inconveniente es la indirecta. Los hooks son más fáciles de seguir en React moderno, mientras que los HOC pueden hacer que las arborescencias de componentes sean más ruidosas en DevTools. Sin embargo, para la gestión de rutas, son limpios.
No dejes que los componentes decidan la política de lanzamiento. Los componentes deben consumir un resultado de bandera, no implementar reglas de agrupación de usuarios, o reglas de refresco de caché.
React Feature Flag Patterns Compared
| Criterio | Contexto + Hook | Componente de alto orden (HOC) |
|---|---|---|
| Mejor caso de uso | Decisiones y variantes de componentes | Envolver páginas completas, rutas o componentes heredados |
| Flexibilidad | Alto | Medio |
| Experiencia del desarrollador | Fuerte en componentes de funciones modernas | Útil cuando los hooks son incómodos |
| Claridad del paquete | Importaciones claras y lecturas directas | Más abstracción en el árbol |
| Pruebas | Fácil de mockear mediante proveedor | Fácil para casos de integración envueltos |
| Mantenibilidad a largo plazo | Generalmente es mejor | Está bien cuando se usa con moderación |
Si estás implementando banderas de características de React por primera vez, comienza con Contexto + Hook. Agrega un HOC solo cuando tengas una necesidad específica para el gating de estilo de envoltura.
Implementar estrategias de lanzamiento y retroceso
Un plan de lanzamiento importa más en el día en que una característica se comporta mal después de su lanzamiento. La interfaz de usuario puede mostrar solo un nuevo botón o pantalla, pero la tarea esencial es decidir quién la ve primero, cómo crece la exposición y cómo puedes cerrarla rápidamente sin esperar a una recompilación.
Rolado porcentual requiere asignación pegada
Percentage rollout only works if assignment is stable. If the same user gets the new checkout on one visit and the old one on the next, support cannot reproduce issues, analytics become noisy, and users lose trust.
La asignación porcentual solo funciona si la asignación es estable. Si el mismo usuario recibe el nuevo pago en una visita y el antiguo en la siguiente, el soporte no puede reproducir los problemas, los análisis se vuelven ruidosos y los usuarios pierden confianza. Math.random() en el navegador no es la herramienta adecuada porque reasigna a los usuarios de manera impredecible.
Un camino de despliegue práctico se ve así:
- Comience con usuarios internos y QA.
- Lanzar a un pequeño grupo de usuarios.
- Ampliar en etapas deliberadas después de verificar las tasas de errores, el impacto de la conversión y los tickets de soporte.
- Mantenga la asignación pegada durante toda la vida de la bandera.
El último punto es fácil de subestimar. Las cohortes pegadas no son solo para experimentos. Hacen que la respuesta a incidentes sea más rápida porque los ingenieros pueden responder a una pregunta básica inmediatamente: ¿a qué usuarios se les expuso?
Si ejecuta experimentos, tamaño antes de enviar. Un calculador de tamaño de muestra de Optimizely muestra cómo el volumen de tráfico, la conversión de línea base y el efecto mínimo detectable cambian el número de usuarios que necesitan por variante (Calculadora de tamaño de muestra de OptimizelySin ese chequeo, los equipos a menudo leen ruido como señal y promueven una característica demasiado pronto.
Una referencia útil para actualizaciones en etapas fuera del navegador es Despliegues escalonados para Capacitor actualizaciones en vivoLa misma disciplina de lanzamiento se aplica cuando la aplicación de React se ejecuta dentro de una caja de concha empaquetada y el reenvío binario es más lento.
Releases dirigidas y basadas en anillos reducen el radio de impacto
Algunas características no deben comenzar con un porcentaje aleatorio. Los flujos de facturación, las solicitudes de permisos, las migraciones de datos y cualquier cosa que pueda bloquear a los usuarios suelen necesitar un lanzamiento dirigido primero.
El objetivo funciona bien cuando el primer público está definido por rasgos conocidos:
- El personal interno para probar el producto
- Los probadores beta que acordaron con las aristas rugosas
- Los niveles de cuenta específicos
- Las regiones con requisitos legales o de idioma distintos
- Devices or app versions that support the feature safely
El lanzamiento basado en anillos hace que ese objetivo sea más operativo. El anillo 0 es el personal. El anillo 1 es los probadores externos confiables. Las anillas posteriores amplían la exposición a medida que mejora la confianza. Esta estructura ayuda a los equipos a evitar el error común de tratar a todos los usuarios como una sola piscina cuando el riesgo es claramente desigual.
Aquí está el recorrido integrado que se adapta bien a este modelo de lanzamiento:
Un interruptor de muerte es la bandera que gana su mantenimiento
Cada característica arriesgada necesita una salida rápida. En la práctica, eso suele significar una bandera de operación de alto nivel que deshabilita todo el flujo de características, no una bandera presentacional que solo oculta un punto de entrada mientras las solicitudes de fondo, los efectos o las rutas de navegación siguen funcionando.
Design the kill switch before launch:
- Evaluate it early in app startup.
- Cache el último valor conocido seguro.
- Elige un valor por defecto seguro si el servicio de banderas no está disponible.
- Asegúrate de que deshabilitar la característica detenga los efectos laterales, no solo la renderización.
- Documente quién puede activarlo durante un incidente.
Para aplicaciones web únicamente, esto reduce el riesgo de lanzamiento. Para aplicaciones móviles y de escritorio de React, puede ser la diferencia entre un incidente menor y esperar días a que los usuarios obtengan una versión corregida. Si la code ya se ha enviado en el paquete, las banderas remotas forman parte de su estrategia de rollback, no solo de su estrategia de lanzamiento.
Pruebas de Observabilidad y Gestión de Deuda de Bandera
La parte fácil de las banderas de características es agregar una. La parte costosa comienza más tarde, cuando hay muchas de ellas y nadie recuerda cuáles todavía importan.
Cada bandera multiplica los estados en los que debes confiar
La advertencia de Martin Fowler todavía es válida: una vez existan banderas de características, los equipos deben validar tanto On y Off Estados y con múltiples flags, las combinaciones de estados posibles crecen de manera combinatoria, lo que aumenta el riesgo de regresión.Martin Fowler sobre interruptores de características).
Eso tiene consecuencias directas para las aplicaciones de React:
- Las rutas de renderizado condicional se propagan rápidamente: Una página puede tener varias ramas antes de que nadie se dé cuenta.
- Se vuelven más fáciles de activar El cliente y el servidor pueden discrepar si el cálculo se produce en el momento incorrecto.
- Snapshot tests become less useful alone: Una renderización exitosa no te dice mucho si el estado de bandera opuesto no está probado.
A una pila de pruebas práctica le parece esto:
- Pruebe la lógica de evaluación mediante pruebas unitarias.
- Claves de prueba de componentes marcadas como ramas.
- Agregue cobertura de principio a fin solo para los caminos riesgosos.
- Verifique los valores por defecto explícitamente.
No busque cada combinación. Eso suele colapsar bajo su propio peso. Pruebe los estados que pueden lastimar a los usuarios o romper el diseño.
La deuda de banderas es real y se vuelve costosa de manera silenciosa
Las banderas antiguas se convierten en una forma de code putrefacción. Quedan en condicionales, comentarios, tableros y runbooks. Luego alguien edita la rama 'temporal' meses después porque nadie la eliminó.
Las reglas de limpieza que funcionan en la práctica son simples:
| Problema | Cómo proceder |
|---|---|
| No hay dueño | Asignar un equipo o persona cuando se crea la bandera |
| No estado final | Decidir si la bandera se eliminará, se mantendrá o se convertirá en configuración |
| La bandera controla demasiado | Divírtala en banderas más pequeñas y estrechas |
| La lógica central está detrás de las banderas | Mueva las reglas de negocio fuera de las condiciones de renderizado |
Regla de limpieza: Cada bandera debe tener un propietario, un propósito y un plan de eliminación desde el primer día.
Esta es también la zona donde los equipos se ven mordidos por 'problemas de confianza'. Un nombre de bandera existe, pero el fallback está mal. La entrada de la consola cambió, pero el tipo de aplicación no. El camino code está muerto, pero todavía es accesible. Por eso, la generación de tipos y la validación de registro importan en sistemas más grandes, incluso si la implementación inicial parecía trivial.
La observabilidad te dice si la bandera ayudó o simplemente existió
Un lanzamiento no está completo porque la bandera alcanzó la exposición completa. Está completo cuando el equipo sabe qué pasó.
Siguientes preguntas mínimas:
- Exposición: ¿Qué usuarios vieron qué variante?
- Errores: ¿Se activaron más errores en el lado del cliente?
- Adopción: ¿Los usuarios utilizaron la característica que expusiste?
- Señales de rollback: ¿Qué umbral haría que lo desactivaras?
Si tu plataforma de banderas no responde a esas preguntas, seguirás adivinando durante las revisiones de lanzamiento.
Seguridad de las banderas y automatización con CI/CD
Un despliegue malo es obvio. Un cambio de bandera malo es más silencioso, y en algunos casos más peligroso, porque cambia el comportamiento de producción sin pasar por el mismo camino de revisión que code.
Trate los cambios de banderas como cambios de producción.
Las banderas de características son controles de lanzamiento. Si un equipo puede cambiar una bandera en producción, ese equipo puede cambiar qué usuarios obtienen, qué rutas code se ejecutan y, a veces, qué integraciones disparan. Eso merece la misma disciplina que el acceso a la implementación.
Los controles mínimos son fáciles de entender:
- Acceso basado en roles: Limitar quién puede cambiar banderas de producción y separar el acceso de lectura del acceso de edición.
- Audit logs: Guardar un registro claro de quién cambió una bandera, cuándo la cambió y qué entorno tocó.
- Aislamiento de entornos: Banderas de staging, preview y producción deben ser distintas para que los cambios de prueba nunca afecten el tráfico en vivo.
- Verificaciones del lado del servidor para decisiones sensibles: Una bandera de cliente puede ocultar la interfaz de usuario. No debe decidir el acceso a facturación, permisos o autorización.
A un error común es tratar la consola de banderas como una hoja de cálculo compartida. El producto activa algo para un cliente. El soporte lo desactiva para detener una queja. El ingeniería asume que nadie lo tocó porque no hubo un despliegue. Ese conjunto funciona hasta que necesitas explicar un incidente.
Bundled apps raise the stakes. In a web app, a code fix can go out quickly. In a Capacitor or desktop app, the broken code may already be sitting on devices, waiting for a remote flag to expose it. Teams building Las aplicaciones móviles de React con Capacitor deben ser aún más estrictos con las reglas de aprobación, porque el rollback a menudo significa deshabilitar una capacidad enviada en lugar de reemplazar el binario.
Coloca las operaciones de bandera dentro del pipeline
Las banderas se vuelven difíciles de confiar cuando viven fuera de tu proceso de entrega. El patrón más seguro es gestionarlas como parte del mismo flujo que envía la característica.
Eso suele significar:
- Crear o actualizar banderas en el mismo PR que la característica code
- Valida las definiciones de banderas tipadas contra el registro remoto durante CI
- Promueve valores predeterminados por entorno con propósito
- Bloquea la liberación si las banderas requeridas están faltando o mal configuradas
- Programar tareas de limpieza para banderas con una fecha de vencimiento o estado de lanzamiento finalizado.
Prefero una regla simple: si un incidente de producción podría ser causado por una bandera, el CI debería poder detectar la configuración antes de la liberación. Esto incluye valores por defecto faltantes, claves renombradas, mapeos de entorno caducos y banderas que existen en code pero no en el plano de control.
Si necesita un punto de partida para la estructura de la canalización Los flujos de trabajo de CI/CD de Git Action son una sólida referencia para controles de compilación, puertas de despliegue y pasos de automatización que puedes extender para la validación de banderas.
Mantén secretos y SDK elecciones aburridas
Los equipos de frontend a menudo complican demasiado la seguridad de las banderas y se pierden en la parte obvia. Las claves de SDK cliente-side públicas suelen estar bien si el proveedor las diseñó para uso en el navegador. Los tokens de administración, las credenciales de escritura y las claves de gestión de entorno no son. Eso pertenece solo a los servicios de backend o al CI.
La división práctica es simple. Utilice la evaluación cliente-side para cambios de presentación y experimentos de bajo riesgo. Utilice la evaluación servidor-side para precios, permisos, interruptores de muerte en flujos sensibles y cualquier cosa que no se confíe en JavaScript local.
Esta frontera importa más en entornos de liberación lenta. Los equipos de web pueden recuperarse con un despliegue rápido. Los equipos de móviles y escritorios a menudo necesitan que el sistema de banderas sea el mecanismo de recuperación. Si las personas equivocadas pueden editar las banderas de producción, o si el CI nunca valida el contrato de la bandera, el rollback se vuelve complicado rápidamente.
Más allá de las banderas de características web para Capacitor y aplicaciones móviles
La mayoría de los artículos sobre banderas de características de React asumen una aplicación web que puede redeployar instantáneamente. Esa suposición se rompe en el momento en que su React code vive dentro Capacitor, Electrono otra ejecución empaquetada.
Bundled apps change the release math
En las aplicaciones híbridas, a menudo envías JavaScript, CSS, activos y configuración dentro de un paquete que los usuarios no actualizarán de inmediato. Una característica podría ya estar en el dispositivo antes de que quieras que nadie la utilice. Eso cambia completamente el papel de las banderas.
Una discusión reciente sobre la estrategia de liberación híbrida señaló que el contenido de banderas de React existente raramente aborda el modelo de riesgo de liberación para Capacitor o Electron. Para esas equipos, la necesidad principal es una capa de orquestación de liberación que combine banderas, canales dirigidos y protección de rollback en lugar de un simple interruptor on/off, especialmente cuando importa evitar retrasos en la revisión de la tienda (discusión de liberación de aplicaciones híbridas).
Exactamente. En las aplicaciones empaquetadas, las banderas son menos sobre la presentación condicional y más sobre activación remota de una capacidad ya enviada.
En una aplicación móvil o de escritorio de React, una bandera a menudo controla el tiempo de liberación más que la presencia de UI.
This is also why channel-based distribution matters. If you’re building hybrid apps and need the app shell plus web code release model to make sense together, Crear aplicaciones móviles de React con Capacitor es un punto de partida práctico.
Flags work best when paired with update delivery
Para equipos móviles y de escritorio, las banderas solas no resolverán todos los problemas de lanzamiento. Pueden ocultar o habilitar rutas code, pero no pueden reemplazar el envío de activos o lógica fijos cuando el bug ya está en el paquete.
Eso es por qué el modelo más potente es:
- Entregar actualizaciones code fuera de los ciclos de tienda completos cuando su plataforma lo permita
- Dirija esas actualizaciones por canal o audiencia
- Y utilice banderas para controlar la activación, el rollback y la exposición estadiada.
Usados juntos, los actualizaciones en vivo y las banderas dan a los equipos híbridos algo más cercano al control de lanzamiento de la web. Eso no elimina la necesidad de disciplina. Solo les da más de un levante cuando algo sale mal.
Si su equipo envía aplicaciones Capacitor o Electron y necesita esa capa de control de lanzamiento, Capgo es una opción a considerar. Entrega paquetes web firmados a canales objetivo, admite protección de rollback y observabilidad, y se ajusta al tipo de flujo de trabajo de aplicaciones híbridas donde las banderas necesitan funcionar junto con las actualizaciones en vivo en lugar de reemplazarlas.
Continúa desde React Feature Flags: Una Guía de Implementación Completa
Si estás utilizando React Feature Flags: Una Guía de Implementación Completa para planificar la ruta de canal y la implementación en etapas, conecta con Canal para los detalles de implementación en los Canales, Canal para los detalles de implementación en los Canales, Canal para los detalles de implementación en los Canales, Solución de Pruebas Beta para el flujo de trabajo del producto en la Solución de Pruebas Beta Solución de Enfoque de Versión para el flujo de trabajo del producto en Solución de Enfoque de Versión.
