Experimentación progresiva con marcas de características

A medida que los equipos de DevOps cambian a una metodología ágil que se centra en la entrega continua de características, la necesidad de controlar la divulgación de nuevas características es cada vez más importante. Tanto si el objetivo es restringir el acceso a esas nuevas características con fines de marketing o para limitar el público para las pruebas en producción,las marcas de características son una excelente solución.

Implementación y exposición del desacobado

Las marcas de características son configuraciones que un equipo puede definir que indican si un conjunto determinado de características está visible en la experiencia del usuario o se invoca dentro de la funcionalidad. Esto permite al equipo compilar e implementar esas características como parte del proceso de desarrollo normal, pero para evitar tener esas características disponibles para un acceso amplio. Ofrecen una manera cómoda de desacoplar la implementación de características de su exposición.

Las marcas proporcionan control en tiempo de ejecución a un usuario individual

Las marcas también proporcionan un control granular hasta el usuario individual. Cuando es el momento de habilitar una característica, ya sea para un usuario, un grupo pequeño o todos los usuarios, el equipo puede cambiar simplemente la marca de característica para encenderla sin tener que volver a implementarla.

El ámbito de una marca de característica variará en función de la naturaleza de la característica y la audiencia. En algunos casos, una marca de característica voltea automáticamente la funcionalidad para todos los usuarios. En otros casos, una característica se habilitará por usuario. Los equipos también pueden optar por usar marcas de características para activar una opción para que los usuarios habiliten una característica, si así lo desean. Realmente no hay ningún límite en la forma en que se implementan las marcas de características.

Compatibilidad con comentarios anticipados, experimentación

Las marcas de características son una excelente manera de admitir la experimentación temprana. Algunas características pueden tener bordes aproximados al principio, que solo pueden ser interesantes para los primeros usuarios. Intentar insertar esas características no preparadas en un público más amplio podría dar lugar a una insatisfaz. Pero la ventaja de recopilar comentarios de aquellos que están dispuestos a tratar con una característica en curso es muy valiosa.

Conmutador de apagado rápido

A veces resulta muy útil poder desactivar algo. Por ejemplo, suponga que una nueva característica no funciona de la manera prevista y que hay efectos secundarios que están causando problemas en otra parte. Las marcas de características son una excelente manera de desactivar rápidamente la nueva funcionalidad para revertir al comportamiento de confianza sin tener que volver a implementar. Aunque las marcas de características se suelen tener en cuenta en términos de características de interfaz de usuario, se pueden usar con la facilidad para los cambios en la arquitectura o la infraestructura.

Fases estándar

Hay un proceso de implementación estándar que Microsoft usa para activar las marcas de características. Hay dos conceptos independientes: los anillos son para las implementaciones y las fases son para las marcas de características. Obtenga más información sobre los anillos y las fases.

Las fases son todo sobre la divulgación o exposición. Por ejemplo, la primera fase podría ser para la cuenta de un equipo y las cuentas personales de los miembros. Es probable que haya una gran cantidad de cosas en ejecución en un servicio en este momento que los usuarios no verán porque las únicas marcas de lugar están activadas es para esta primera fase. Esto permite que un equipo use completamente y experimente con él. Una vez que el equipo cierra la sesión, los clientes seleccionados podrán participar en él a través de la segunda fase de las marcas de características.

Participar

Es un procedimiento recomendado permitir que los usuarios opten por las marcas de características cuando sea factible. Por ejemplo, el equipo puede exponer un panel de vista previa asociado a las preferencias o la configuración del usuario.

Uso de marcas con telemetría

Con las marcas de características, los equipos tienen una manera de exponer actualizaciones de forma incremental. Pero para medir completamente la preparación para una exposición más amplia, los equipos deben supervisar continuamente las métricas correctas. Estas métricas deben incluir el comportamiento del uso, así como el impacto de las actualizaciones en el estado del sistema. Es importante evitar la trampa de asumir que todo está bien solo porque parece que no ocurre nada malo.

Ejemplo de marca de características

Considere el ejemplo siguiente. El equipo ha agregado un par de botones aquí para Cherry-pick y Revert en la interfaz de usuario de la solicitud de extracción. Se implementaron mediante marcas de características.

Definición de marcas de características

La primera característica expuesta fue el botón Revertir. En el caso de este producto, la solución usa un archivo XML para definir todas las marcas de características. En este caso, hay un archivo por servicio. Esto garantiza que si un equipo termina con su sección siendo muy larga, es evidente que es el momento de limpiarlos. Eliminarán marcas antiguas porque hay una motivación natural para controlar el tamaño de ese archivo.

<?xml version="1.0" encoding="utf-8"?>
<!--
  In this group we should register Azure DevOps specific features and sets their states.
-->
<ServicingStepGroup name="AzureDevOpsFeatureAvailability" … >
  <Steps>
    <!-- Feature Availability -->
    <ServicingStep name="Register features" stepPerformer="FeatureAvailability" … >
      <StepData>
        <!--specifying owner to allow implicit removal of features -->
        <Features owner="AzureDevOps">
           <!-- Begin TFVC/Git -->
           <Feature name="SourceControl.Revert" description="Source control revert features" />

Tener un marco de servidor común permite una gran cantidad de reutilización y economías de escala en todo el equipo. Lo ideal es que el proyecto tenga infraestructura para que un desarrollador pueda definir simplemente una marca en un almacén central y controlar el resto de la infraestructura.

Comprobación de marcas de características en tiempo de ejecución

La marca de característica que se usa aquí se denomina SourceControl.Revert. Este es el typescript real de esa página que muestra la llamada para una comprobación de disponibilidad de características.

private addRevertButton(): void {
 if (FeatureAvailability.isFeatureEnabled(Flags.SourceControlRevert)) {
     this._calloutButtons.unshift(
         <button onClick={ () => Dialogs.revertPullRequest(
             this.props.repositoryContext,
             this.props.pullRequest.pullRequestContract(),
             this.props.pullRequest.branchStatusContract().sourceBranchStatus,
             this.props.pullRequest.branchStatusContract().targetBranchStatus)
         }
         >
             {VCResources.PullRequest_Revert_Button}
         </button>
        );
     }
}

En el ejemplo anterior se muestra el uso en TypeScript, pero se puede acceder fácilmente desde C#. El código comprueba si la característica está habilitada y, si es así, representa un botón para proporcionar la funcionalidad. Si la marca no está habilitada, se omite el botón.

Controlar una marca de característica

Una buena plataforma de marcas de características proporcionará varias maneras de administrar si se establece una marca determinada. Normalmente, hay escenarios de uso para que la marca se controle a través de PowerShell y la interfaz web. Para PowerShell, todo lo que realmente debe exponerse son formas de obtener y establecer el estado de una marca de característica, junto con parámetros opcionales para elementos como identificadores de cuenta de usuario específicos (si procede).

Control de marcas de características a través de la interfaz de usuario web

A continuación se muestra un ejemplo del uso de la interfaz de usuario web expuesta para este producto por el equipo. Anote la marca de características de SourceControl.Revert. Hay dos cuentas personales enumeradas aquí: hallux y buckh-westuya. El estado se establece para hallux, que se encuentra en Centro-norte y se borra para la otra cuenta en Oeste de Europa.

La naturaleza de la marca de características impulsará la forma en que se exponen las características. En algunos casos, la exposición seguirá un anillo y un modelo de fase. En otros casos, los usuarios pueden participar a través de la interfaz de usuario de configuración o incluso mediante un correo electrónico al equipo para obtener acceso.

Consideraciones sobre las marcas de características

La mayoría de las marcas de características se pueden retirar una vez que se haya implantado una característica para todos los usuarios. En ese momento, el equipo puede eliminar todas las referencias a la marca en el código y la configuración. Es una buena práctica incluir una revisión de marca de características, como al principio de cada sprint.

Al mismo tiempo, puede haber un conjunto de marcas de características que son persistentes por diversos motivos. Por ejemplo, es posible que el equipo quiera mantener una marca de características que bifurca algo de infraestructura durante un período de tiempo después de que el servicio de producción se haya cambiado por completo. Sin embargo, tenga en cuenta que esta ruta de código potencial podría reactivarse en el futuro durante una desactivación explícita de la marca de característica, por lo que debe probarse y mantenerse hasta que se quite la opción.

Marcas de características y estrategia de bifurcación

Las marcas de características permiten a los equipos de desarrollo incluir características incompletas en main sin afectar a nadie más. Siempre que la ruta de acceso del código esté aislada detrás de una marca de característica, por lo general es seguro compilar y publicar ese código sin efectos secundarios que afectan al uso normal. Pero si hay casos en los que una característica requiere dependencias, como cuando se expone un punto de conexión REST, los equipos deben tener en cuenta cómo esas dependencias pueden crear trabajo de seguridad o mantenimiento incluso sin exponer la característica.

Marcas de características para mitigar el riesgo

A veces, las nuevas características tienen la posibilidad de introducir cambios destructivos o perjudiciales. Por ejemplo, el producto puede estar experimentando una transformación de un esquema de base de datos ancho a uno largo. En ese escenario, el desarrollador debe crear una rama de características durante una pequeña cantidad de tiempo. A continuación, hacen los cambios desestabilizadores en la rama y mantienen la característica detrás de una marca. Una práctica popular es que los equipos combinen los cambios en cuanto no causan main ningún daño. Esto no sería factible sin la capacidad de mantener oculta la característica sin terminar detrás de una marca de característica.

Las marcas de características ayudan a trabajar en main

Trabajar en es una buena manera de reforzar un ciclo de DevOps, siempre que siga las prácticas de sentido común main descritas en la fase de desarrollo. Cuando se combinan con marcas de características, los desarrolladores pueden combinar rápidamente sus características ascendentes e insertarlas a través del gauntlet de prueba. Esto garantiza que el código de calidad se publique rápidamente para las pruebas en producción. Después de unos pocos sprints, los desarrolladores reconocerán rápidamente las ventajas de usar marcas de características y de usarlos de forma proactiva.

Cómo decidir si se debe usar una marca de característica

Los equipos de características tienen la decisión de si necesitan una marca de característica o no para un cambio determinado. No todos los cambios requieren uno, por lo que es un criterio para un desarrollador cuando elige realizar un cambio determinado. En el caso de la característica Revertir que se ha analizado anteriormente, era importante usar una marca de característica porque significaba que el equipo podía poner la característica en producción con exposición controlada. Permitir que los equipos sean propietarios de decisiones clave sobre su área de características forma parte de la habilitación de la autonomía en una organización de DevOps eficaz.

Compilación frente a compra

Aunque cada equipo tiene la opción de crear su propia infraestructura de marca de características, se recomienda que adopte una plataforma como LaunchDarkly,si es posible. Es preferible invertir en la creación de características en lugar de recompilar la funcionalidad de la marca de características.

Pasos siguientes

Obtenga más información sobre el uso de marcas de características en una ASP.NET Core.