Un equipo despliega correctamente una pantalla de aprobaciones, pero operaciones no está preparada hasta la próxima formación. Otra función debe probarse con un cliente antes de ofrecerla a todos. Estas situaciones muestran que desplegar código y hacer disponible una capacidad son decisiones relacionadas, pero distintas.
Los indicadores de función, o feature flags, permiten esa separación. La aplicación elige entre comportamientos definidos mediante configuración o reglas de destinatarios. Su valor está en controlar la exposición y disponer de recuperación clara; sin responsables ni retirada también pueden acumular ramas permanentes confusas que nadie entiende por completo.
Define la decisión de publicación que representa el indicador
Nombra la capacidad y el motivo para controlar su disponibilidad. Un despliegue gradual temporal, un control operativo de parada y un derecho permanente de producto tienen ciclos de vida distintos. Evita esconderlos todos detrás de un booleano sin documentar porque su código se parezca.
En un portal hipotético de mantenimiento, se podría ofrecer un proceso nuevo de informes de visita a una oficina regional. Especifica qué cambia para ella, qué sigue compartido y qué pruebas permitirían ampliar. El indicador debe apoyar una decisión concreta, en lugar de un estado indefinido de «casi publicado».
La documentación de Microsoft describe bibliotecas y selección de destinatarios para disponibilidad controlada. Evalúa lo necesario y mantén la configuración comprensible para quienes operarán la publicación. Gestión de funciones de Azure App Configuration.
Elige una audiencia que aporte pruebas útiles
Selecciona deliberadamente a los primeros usuarios. Deben representar el proceso y poder comunicar problemas, además de ser cuentas fáciles de añadir. Incluye diferencias pertinentes de dispositivos, permisos y datos.
Define cómo se determina la pertenencia y se mantiene consistente. Un cliente no debe pasar inesperadamente entre comportamientos durante una tarea porque cada componente evalúa con otro identificador. Decide dónde evaluar y cómo propagar el resultado cuando importe la consistencia.
Utiliza identificadores y acceso adecuados para los datos de selección. Un indicador no sustituye la autorización. El servidor debe comprobar permisos incluso cuando un cliente solicita directamente una capacidad oculta en la interfaz.
Diseña ambas vías como comportamientos admitidos
Describe las vías antigua y nueva para poder probarlas. Considera registros creados con cada una y si los usuarios pueden pasar entre ellas. Si la nueva escribe información que la antigua no interpreta, apagar el indicador quizá no restaure el estado operativo anterior.
En el informe de visita, un formato nuevo puede exigir pruebas adicionales. Decide cómo lo muestran pantallas antiguas y qué ocurre con un borrador al cambiar el indicador. Incorpora las transiciones a la aceptación, sin dejarlas al primer usuario que las encuentre.
Sitúa deliberadamente las reglas compartidas. Un indicador no debe crear silenciosamente dos interpretaciones incompatibles de autoridad o facturación. Cuando se diferencie el comportamiento a propósito, documéntalo y conserva contexto para explicar qué versión se aplicó a una transacción.
Trata la desactivación como una acción operativa probada
Decide qué hace realmente desactivar. Puede impedir solicitudes nuevas y dejar terminar las aceptadas, o bloquear una acción externa concreta. Quitar un botón no detiene necesariamente procesos, tareas programadas o clientes API que realizan la misma operación.
Define la propagación esperada y el comportamiento si falta temporalmente la configuración. Utiliza un valor predeterminado acorde al riesgo y disponibilidad. No describas el control como inmediato si implementación y condiciones no respaldan esa promesa.
Ensaya desactivar y reactivar en un entorno representativo. Observa trabajos pendientes, formularios abiertos y procesos parciales. Da a soporte un procedimiento breve que explique qué verá el usuario y cómo comprobar que el cambio surtió efecto.
Mide los resultados del grupo expuesto
Registra contexto suficiente para comparar la vía nueva con la referencia pertinente. Pueden servir finalización, validaciones fallidas, tiempos y avisos de soporte. Interpreta según el diseño de publicación: un piloto pequeño seleccionado no es automáticamente un experimento controlado.
Inspecciona excepciones además de medias. Una función puede servir a la mayoría y fallar para un permiso o patrón importante. Recoge ejemplos reproducibles y distingue defectos de malentendidos de formación o proceso para corregir la causa real.
Define criterios de ampliación antes de que domine el entusiasmo. El equipo debe saber qué pruebas permiten ampliar, mantener el grupo o desactivar. Nombra a quien decide y explica las consecuencias operativas.
Retira deliberadamente los indicadores temporales
Asigna responsable y fecha de revisión al crearlos. Cuando termine el despliegue gradual y la vía antigua no haga falta, elimina la rama obsoleta, las reglas de selección y las pruebas exclusivas de la transición. Conserva las que protegen el comportamiento final.
Revisa interacciones entre indicadores. Varios controles sencillos pueden crear combinaciones nunca probadas. Evita un lenguaje accidental de configuración cuyos estados válidos solo conoce una persona. Consolida o simplifica cuando termine su finalidad original.
Worktechlabs introduce publicaciones controladas en la entrega .NET. Combina indicadores con despliegues recuperables y señales útiles para decidir según la experiencia real, con respuesta probada y un final claro para la complejidad temporal.
Fuentes oficiales y lecturas adicionales
- Microsoft: gestión de funciones — bibliotecas y selección de destinatarios.
- Microsoft: patrón CQRS — consistencia al publicar sobre vías separadas de lectura y escritura.
