Descripción de las reglas de marca de características con múltiples variantes - AWS AppConfig

Descripción de las reglas de marca de características con múltiples variantes

Al crear una variante de marca de características, debe especificar una regla para ella. Las reglas son expresiones que toman valores de contexto como entrada y producen un resultado booleano como salida. Por ejemplo, puede definir una regla para seleccionar una variante de marca para los usuarios de la versión beta, identificados por su ID de cuenta, para probar una actualización de la interfaz de usuario. En esta situación, haga lo siguiente:

  1. Cree un nuevo perfil de configuración de marca de características denominado UI Refresh.

  2. Cree una nueva marca de características denominada ui_refresh.

  3. Edite la marca de características después de crearla para añadir variantes.

  4. Cree y habilite una nueva variante denominada BetaUsers.

  5. Defina una regla para BetaUsers que seleccione la variante si el ID de cuenta del contexto de la solicitud figura en una lista de ID de cuenta aprobados para ver la nueva experiencia beta.

  6. Confirme que el estado de la variante predeterminada sea Deshabilitado.

nota

Las variantes se evalúan como una lista ordenada en función del orden en que están definidas en la consola. La variante que aparece en la parte superior de la lista se evalúa en primer lugar. Si ninguna regla coincide con el contexto proporcionado, AWS AppConfig devuelve la variante predeterminada.

Cuando AWS AppConfig procesa la solicitud de marca de características, compara primero el contexto proporcionado, que incluye AccountID (por ejemplo), con la variante BetaUsers. Si el contexto coincide con la regla de BetaUsers, AWS AppConfig devuelve los datos de configuración de la experiencia beta. Si el contexto no incluye un ID de cuenta o si el ID de cuenta termina en un número distinto de 123, AWS AppConfig devuelve los datos de configuración de la regla predeterminada, lo que significa que el usuario ve la experiencia actual en producción.

nota

Para obtener más información sobre de la recuperación de marcas de características con múltiples variantes, consulte. Recuperación de marcas de características básicas y con múltiples variantes

Descripción del operador de división

En la siguiente sección se describe cómo se comporta el operador de split cuando se utiliza en diferentes escenarios. A modo de recordatorio, split evalúa como true un porcentaje de tráfico determinado en función de un hash coherente de los valores de contexto proporcionados. Para entenderlo mejor, considere el siguiente escenario de referencia, que utiliza la división con dos variantes:

A: (split by::$uniqueId pct::20) C: <no rule>

Como cabe esperar, si se proporciona un conjunto de valores uniqueId aleatorio, se obtiene una distribución que es aproximadamente:

A: 20% C: 80%

Si añade una tercera variante, pero utiliza el mismo porcentaje de división, de la siguiente manera:

A: (split by::$uniqueId pct::20) B: (split by::$uniqueId pct::20) C: <default>

Se obtiene la siguiente distribución:

A: 20% B: 0% C: 80%

Esta distribución, potencialmente inesperada, se obtiene porque cada regla de variante se evalúa en orden y la primera coincidencia determina la variante devuelta. Cuando se evalúa la regla A, el 20 % de los valores uniqueId coinciden con ella, por lo que se devuelve la primera variante. A continuación, se evalúa la regla B. Sin embargo, todos los valores uniqueId que habrían coincidido con la segunda instrucción de división ya coincidían con la regla A de variante, por lo que ningún valor coincide con la regla B. En su lugar, se devuelve la variante predeterminada.

Veamos ahora un tercer ejemplo.

A: (split by::$uniqueId pct::20) B: (split by::$uniqueId pct::25) C: <default>

Como en el ejemplo anterior, el primer 20 % de los valores uniqueId coinciden con la regla A. En el caso de la regla B de variante, el 25 % de todos los valores uniqueId coincidirían, pero la mayoría de los valores coincidieron previamente con la regla A. Eso deja un 5 % del total de los valores para la variante B y el resto recibirá la variante C. La distribución tendría el siguiente aspecto:

A: 20% B: 5% C: 75%
Uso de la propiedad seed

Puede utilizar la propiedad seed para garantizar que el tráfico se divida de forma coherente para un valor de contexto determinado, independientemente de dónde se utilice el operador de división. Si no lo especifica seed, el hash es coherente a nivel local, lo que significa que el tráfico se dividirá de forma coherente para esa marca, pero otras marcas que reciban el mismo valor de contexto pueden dividir el tráfico de forma diferente. Si se proporciona seed, se garantiza que cada valor único dividirá el tráfico de forma coherente entre las marcas de características, los perfiles de configuración y las Cuentas de AWS.

Por lo general, los clientes utilizan el mismo valor seed en todas las variantes de una marca al dividir el tráfico en la misma propiedad de contexto. Sin embargo, en ocasiones puede tener sentido utilizar un valor de inicio diferente. Aquí se incluye un ejemplo que utiliza distintos valores de inicio para las reglas A y B:

A: (split by::$uniqueId pct::20 seed::"seed_one") B: (split by::$uniqueId pct::25 seed::"seed_two") C: <default>

Como en el ejemplo anterior, el 20 % de los valores uniqueId coincidentes coinciden con la regla A. Esto significa que el 80 % de los valores no coinciden y se comparan con la regla B de variante. Como el valor de inicio es diferente, no existe correlación entre los valores que coincidían con la regla A y los valores que coinciden con la regla B. Sin embargo, solo hay un 80 % de valores uniqueId para dividir, de modo que el 25 % de ese número coincide con la regla B y el 75 % no. Esto da lugar a la siguiente distribución:

A: 20% B: 20% (25% of what falls through from A, or 25% of 80%) C: 60%