Gestione delle funzionalità Python
La libreria di gestione delle funzionalità Python consente di sviluppare ed esporre funzionalità dell'applicazione in base ai flag di funzionalità. Una volta sviluppata una nuova funzionalità, molte applicazioni hanno requisiti speciali, ad esempio relativamente a quando la funzionalità deve essere abilitata e in quali condizioni. Questa libreria consente di definire queste relazioni e si integra anche in criteri di codice Python comuni per consentire l'esposizione di queste funzionalità.
I flag di funzionalità consentono alle applicazioni Python di attivare o disattivare dinamicamente le funzionalità. Gli sviluppatori possono usare flag di funzionalità in casi d'uso semplici, ad esempio istruzioni condizionali.
Ecco alcuni dei vantaggi dell'uso della libreria di gestione delle funzionalità Python:
Una convenzione comune per la gestione delle funzionalità
Bassa barriera all'ingresso
- Supporta la configurazione del flag di funzionalità JSON
Gestione della durata dei flag di funzionalità
- I valori di configurazione possono cambiare in tempo reale; i flag di funzionalità possono essere coerenti nell'intera richiesta
Scenari semplici e complessi trattati
- Attivare/disattivare le funzionalità tramite il file di configurazione dichiarativo
- Valutare dinamicamente lo stato della funzionalità in base alla chiamata al server
La libreria di gestione delle funzionalità Python è open source. Per altre informazioni, visitare il repository GitHub.
Flag di funzionalità
I flag di funzionalità sono costituiti da due parti, un nome e un elenco di filtri di funzionalità usati per attivare la funzionalità.
Filtri di funzionalità
I filtri di funzionalità definiscono uno scenario per il momento in cui è necessario abilitare una funzionalità. Quando viene valutato se una funzionalità è attivata o disattivata, il relativo elenco di filtri di funzionalità viene attraversato fino a quando uno dei filtri non decide che la funzionalità deve essere abilitata. A questo punto, la funzionalità viene considerata abilitata e l'attraversamento dei filtri di funzionalità si arresta. Se nessun filtro di funzionalità indica che la funzionalità deve essere abilitata, questa viene considerata disattivata.
Ad esempio, è possibile progettare un filtro di funzionalità del browser Microsoft Edge. Questo filtro di funzionalità attiverà tutte le funzionalità a cui è collegato, purché una richiesta HTTP provenga da Microsoft Edge.
Configurazione del flag di funzionalità
Per definire i flag di funzionalità viene usato un dizionario Python. Il dizionario è composto da nomi di funzionalità come chiavi e oggetti flag di funzionalità come valori. L'oggetto flag di funzionalità è un dizionario che contiene una conditions chiave, che contiene la client_filters chiave stessa. La chiave client_filters è un elenco di filtri di funzionalità usati per determinare se la funzionalità deve essere abilitata.
Dichiarazione del flag di funzionalità
La libreria di gestione delle funzionalità supporta json come origine del flag di funzionalità. Di seguito è riportato un esempio del formato usato per configurare i flag di funzionalità in un file JSON.
{
"feature_management": {
"feature_flags": [
{
"id": "FeatureT",
"enabled": "true"
},
{
"id": "FeatureU",
"enabled": "false"
},
{
"id": "FeatureV",
"enabled": "true",
"conditions": {
"client_filters": [
{
"name": "Microsoft.TimeWindow",
"parameters": {
"Start": "Wed, 01 May 2019 13:59:59 GMT",
"End": "Mon, 01 Jul 2019 00:00:00 GMT"
}
}
]
}
}
]
}
}
La sezione feature_management del documento JSON viene usata per convenzione per caricare le impostazioni dei flag di funzionalità. La sezione feature_flags è un elenco dei flag di funzionalità caricati nella libreria. Nella sezione precedente vengono visualizzate tre differenti funzionalità. Le funzionalità definiscono i relativi filtri di funzionalità usando la proprietà client_filters, all'interno di conditions. Nei filtri di funzionalità per FeatureT, si noterà che enabled è attivato senza filtri definiti, con FeatureT che restituisce sempre true.
FeatureU è uguale a FeatureT ma con enabled è false e la funzionalità restituisce sempre false.
FeatureV specifica un filtro di funzionalità denominato Microsoft.TimeWindow.
FeatureV è un esempio di filtro di funzionalità configurabile. Nell'esempio è possibile osservare che il filtro ha una proprietà parameters. La proprietà parameters viene utilizzata per configurare il filtro. In questo caso, vengono configurati gli orari di inizio e fine per la funzionalità da attivare.
Lo schema dettagliato della sezione feature_management è disponibile qui.
Avanzate: l'utilizzo dei due punti ':' non è consentito nei nomi dei flag di funzionalità.
Dichiarazione on/off
Il frammento di codice seguente illustra un modo alternativo per definire una funzionalità che può essere usata per le funzionalità on/off.
{
"feature_management": {
"feature_flags": [
{
"id": "FeatureT",
"enabled": "true"
},
{
"id": "FeatureX",
"enabled": "false"
}
]
}
}
Requirement_type
La proprietà requirement_type di un flag di funzionalità viene utilizzata per determinare se i filtri devono usare l logica Any o All durante la valutazione dello stato di una funzionalità. Se requirement_type non è specificato, il valore predefinito è Any.
-
Anysignifica che, per abilitare la funzionalità, è necessario che un solo filtro venga valutato come vero. -
Allindica che ogni filtro deve essere valutato come vero per abilitare la funzionalità.
Un oggetto requirement_type di All modifica l'attraversamento. In primo luogo, se non sono presenti filtri, la funzionalità è disabilitata. I filtri di funzionalità vengono quindi attraversati fino a quando uno dei filtri non decide che la funzionalità deve essere disabilitata. Se nessun filtro indica che la funzionalità deve essere disabilitata, questa viene considerata abilitata.
{
"feature_management": {
"feature_flags": [
{
"id": "FeatureW",
"enabled": "true",
"conditions": {
"requirement_type": "All",
"client_filters": [
{
"name": "Microsoft.TimeWindow",
"parameters": {
"Start": "Wed, 01 May 2019 13:59:59 GMT",
"End": "Mon, 01 Jul 2019 00:00:00 GMT"
}
},
{
"name": "Percentage",
"parameters": {
"Value": "50"
}
}
]
}
},
]
}
}
Nell'esempio precedente, FeatureW specifica un requirement_type di All, ovvero tutti i relativi filtri devono essere valutati come vero per abilitare la funzionalità. In questo caso, la funzionalità è abilitata per il 50% degli utenti durante l'intervallo di tempo specificato.
Consumo
La forma di base di gestione delle funzionalità consiste nel verificare se un flag di funzionalità è abilitato ed eseguire azioni in base al risultato. Il controllo dello stato di un flag di funzionalità viene eseguito tramite il metodo is_enabled di FeatureManager.
…
feature_manager = FeatureManager(feature_flags)
…
if feature_manager.is_enabled("FeatureX"):
# Do something
L'oggetto feature_flags fornito a FeatureManager può essere AzureAppConfigurationProvider o un dizionario di flag di funzionalità.
Implementazione di un filtro di funzionalità
La creazione di un filtro di funzionalità consente di abilitare le funzionalità in base ai criteri definiti dall'utente. Per implementare un filtro di funzionalità, è necessario implementare l'interfaccia FeatureFilter.
FeatureFilter ha un solo metodo denominato evaluate. Quando una funzionalità specifica che può essere abilitata per un filtro di funzionalità, viene chiamato il metodo evaluate. Se evaluate restituisce true, significa che la funzionalità deve essere abilitata.
Il frammento di codice seguente illustra come aggiungere un filtro di funzionalità MyCustomFilter personalizzato.
feature_manager = FeatureManager(feature_flags, feature_filters=[MyCustomFilter()])
I filtri delle funzionalità vengono registrati fornendoli alla proprietà feature_filters durante la creazione di FeatureManager. Se un filtro di funzionalità personalizzato richiede qualsiasi contesto, può essere passato durante la chiamata is_enabled tramite kwargs.
Attributo alias filtro
Quando un filtro di funzionalità viene registrato per un flag di funzionalità, il nome del filtro viene usato come alias per impostazione predefinita.
L'identificatore per il filtro di funzionalità può essere sottoposto a override tramite @FeatureFilter.alias("MyFilter"). Un filtro di funzionalità può essere decorato con questo attributo per dichiarare il nome che deve essere usato nella configurazione per fare riferimento a questo filtro di funzionalità all'interno di un flag di funzionalità.
Filtri delle funzionalità mancanti
Se una funzionalità è configurata per essere abilitata per un filtro di funzionalità specifico e tale filtro di funzionalità non viene registrato, viene generata un'eccezione ValueError quando viene valutata la funzionalità.
Filtri di funzionalità predefiniti
Sono disponibili due filtri di funzionalità disponibili con il pacchetto FeatureManagement: TimeWindowFilter e TargetingFilter.
Ognuno dei filtri di funzionalità predefiniti ha i propri parametri. Ecco l'elenco dei filtri delle funzionalità insieme agli esempi.
Microsoft.TimeWindow
Questo filtro offre la possibilità di abilitare una funzionalità in base a una finestra temporale. Se viene specificato solo End, la funzionalità viene considerata fino a quel momento. Se viene specificato solo Start, la funzionalità viene considerata in tutti i punti dopo tale periodo.
"client_filters": [
{
"name": "Microsoft.TimeWindow",
"parameters": {
"Start": "Wed, 01 May 2019 13:59:59 GMT",
"End": "Mon, 01 Jul 2019 00:00:00 GMT"
}
}
]
Microsoft.Targeting
Questo filtro offre la possibilità di abilitare una funzionalità per un pubblico di destinazione. Una spiegazione approfondita della destinazione è illustrata nella sezione di destinazione seguente. I parametri di filtro includono un oggetto Audience che descrive utenti, gruppi, utenti/gruppi esclusi e una percentuale predefinita della base di utenti che deve avere accesso alla funzionalità. Ogni oggetto gruppo elencato nella sezione Groups deve specificare anche la percentuale di accesso ai membri del gruppo. Se nella sezione Exclusion viene specificato un utente, sia direttamente che se l'utente si trova in un gruppo escluso, la funzionalità è disabilitata. In caso contrario, se un utente viene specificato direttamente nella sezione Users, se l'utente si trova nella percentuale di implementazione inclusa di uno dei gruppi o se rientra nella percentuale di implementazione predefinita, tale utente avrà la funzionalità abilitata.
"client_filters": [
{
"name": "Microsoft.Targeting",
"parameters": {
"Audience": {
"Users": [
"Jeff",
"Alicia"
],
"Groups": [
{
"Name": "Ring0",
"RolloutPercentage": 100
},
{
"Name": "Ring1",
"RolloutPercentage": 50
}
],
"DefaultRolloutPercentage": 20,
"Exclusion": {
"Users": [
"Ross"
],
"Groups": [
"Ring2"
]
}
}
}
}
]
Selezione della destinazione
La destinazione è una strategia di gestione delle funzionalità che consente agli sviluppatori di implementare progressivamente nuove funzionalità alla base degli utenti. La strategia si basa sul concetto di destinazione di un set di utenti noto come gruppo di destinatari. Un gruppo di destinatari è costituito da utenti, gruppi specifici, utenti/gruppi esclusi e una percentuale designata dell'intera base di utenti. I gruppi inclusi nel gruppo di destinatari possono essere suddivisi ulteriormente in percentuali dei membri totali.
I passaggi seguenti illustrano un esempio di implementazione progressiva per una nuova funzionalità "Beta":
- Ai singoli utenti Jeff e Alicia viene concesso l'accesso alla versione Beta
- Un altro utente, Mark, chiede di acconsentire esplicitamente ed è incluso.
- Il venti percento di un gruppo noto come utenti "Ring1" è incluso nella Beta.
- Il numero di utenti "Ring1" inclusi nella Beta è salito fino al 100%.
- Il 5% della base di utenti è incluso nella versione Beta.
- La percentuale di implementazione viene incrementata fino al 100% e la funzionalità viene implementata completamente.
Questa strategia per l'implementazione di una funzionalità è incorporata nella libreria tramite il filtro di funzionalità Microsoft.Targeting incluso.
Destinazione di un utente
Un utente può essere specificato direttamente nella chiamata is_enabled oppure TargetingContext può essere usato per specificare l'utente e il gruppo facoltativo.
# Directly specifying the user
result = is_enabled(feature_flags, "test_user")
# Using a TargetingContext
result = is_enabled(feature_flags, TargetingContext(user_id="test_user", groups=["Ring1"]))
Esclusione di destinazione
Quando si definisce un gruppo di destinatari, gli utenti e i gruppi possono essere esclusi dal gruppo di destinatari. Le esclusioni sono utili quando viene implementata una funzionalità a un gruppo di utenti, ma è necessario escludere alcuni utenti o gruppi dall'implementazione. L'esclusione viene definita aggiungendo un elenco di utenti e gruppi alla proprietà Exclusion del gruppo di destinatari.
"Audience": {
"Users": [
"Jeff",
"Alicia"
],
"Groups": [
{
"Name": "Ring0",
"RolloutPercentage": 100
}
],
"DefaultRolloutPercentage": 0
"Exclusion": {
"Users": [
"Mark"
]
}
}
Nell'esempio precedente la funzionalità è abilitata per gli utenti denominati Jeff e Alicia. È anche abilitata per gli utenti nel gruppo denominato Ring0. Tuttavia, se l'utente è denominato Mark, la funzionalità è disabilitata, indipendentemente dal fatto che si trovino nel gruppo Ring0 o meno. Le esclusioni hanno la priorità rispetto al resto del filtro di destinazione.
Varianti
Quando vengono aggiunte nuove funzionalità a un'applicazione, potrebbe verificarsi un momento in cui una funzionalità include differenti opzioni di progettazione proposte. Una soluzione comune per decidere una progettazione è una forma di test A/B. Il test A/B implica la fornitura di una versione differente della funzionalità a differenti segmenti della base di utenti e la scelta di una versione in base all'interazione dell'utente. In questa libreria, la funzionalità è abilitata rappresentando differenti configurazioni di una funzionalità con varianti.
Le varianti consentono a un flag di funzionalità di diventare più di un semplice flag on/off. Una variante rappresenta un valore di un flag di funzionalità che può essere una stringa, un numero, un valore booleano o anche un oggetto di configurazione. Un flag di funzionalità che dichiara le varianti deve definire in quali circostanze deve essere usata ogni variante, descritta in modo più dettagliato nella sezione Allocazione varianti.
class Variant:
def __init__(self, name: str, configuration: Any):
self._name = name
self._configuration = configuration
@property
def name(self) -> str:
"""
The name of the variant.
:rtype: str
"""
return self._name
@property
def configuration(self) -> Any:
"""
The configuration of the variant.
:rtype: Any
"""
return self._configuration
Recupero di varianti
Per ogni funzionalità, è possibile recuperare una variante usando il metodo FeatureManager del get_variant.
…
variant = print(feature_manager.get_variant("TestVariants", TargetingContext(user_id="Adam"))
variantConfiguration = variant.configuration;
// Do something with the resulting variant and its configuration
La variante restituita dipende dall'utente attualmente in fase di valutazione e le informazioni vengono ottenute da un'istanza di TargetingContext.
Dichiarazione dei flag di funzionalità delle varianti
Rispetto ai normali flag di funzionalità, i flag di funzionalità delle varianti hanno due proprietà in più: variants e allocation. La proprietà variants è un array che contiene le varianti definite per questa funzionalità. La proprietà allocation definisce la modalità di allocazione di queste varianti per la funzionalità. Come per dichiarare i normali flag di funzionalità, è possibile configurare flag di funzionalità delle varianti in un file JSON. Di seguito è riportato un esempio di flag di funzionalità delle varianti.
{
"feature_management": {
"feature_flags": [
{
"id": "MyVariantFeatureFlag",
"enabled": true,
"allocation": {
"default_when_enabled": "Small",
"group": [
{
"variant": "Big",
"groups": [
"Ring1"
]
}
]
},
"variants": [
{
"name": "Big"
},
{
"name": "Small"
}
]
}
]
}
}
Definizione di varianti
Ogni variante ha due proprietà: un nome e una configurazione. Il nome viene usato per fare riferimento a una variante specifica e la configurazione è il valore di tale variante. La configurazione può essere impostata usando la proprietà configuration_value.
configuration_value è una configurazione inline che può essere una stringa, un numero, un valore booleano o un oggetto di configurazione. Se configuration_value non viene specificato, la proprietà Configuration della variante restituita è None.
Un elenco di tutte le possibili varianti viene definito per ogni funzionalità nella proprietà variants.
{
"feature_management": {
"feature_flags": [
{
"id": "MyVariantFeatureFlag",
"variants": [
{
"name": "Big",
"configuration_value": {
"Size": 500
}
},
{
"name": "Small",
"configuration_value": {
"Size": 300
}
}
]
}
]
}
}
Allocazione di varianti
Il processo di allocazione delle varianti di una funzionalità è determinato dalla proprietà allocation della funzionalità.
"allocation": {
"default_when_enabled": "Small",
"default_when_disabled": "Small",
"user": [
{
"variant": "Big",
"users": [
"Marsha"
]
}
],
"group": [
{
"variant": "Big",
"groups": [
"Ring1"
]
}
],
"percentile": [
{
"variant": "Big",
"from": 0,
"to": 10
}
],
"seed": "13973240"
},
"variants": [
{
"name": "Big",
"configuration_value": "500px"
},
{
"name": "Small",
"configuration_value": "300px"
}
]
L'impostazione allocation di una funzionalità ha le proprietà seguenti:
| Proprietà | Descrizione |
|---|---|
default_when_disabled |
Specifica quale variante deve essere utilizzata quando viene richiesta una variante mentre la funzionalità viene considerata disabilitata. |
default_when_enabled |
Specifica quale variante deve essere utilizzata quando viene richiesta una variante mentre la funzionalità viene considerata abilitata e nessun'altra variante è stata assegnata all'utente. |
user |
Specifica una variante e un elenco di utenti a cui deve essere assegnata tale variante. |
group |
Specifica una variante e un elenco di gruppi. La variante viene assegnata se l'utente si trova in almeno uno dei gruppi. |
percentile |
Specifica una variante e un intervallo percentuale in base al quale deve essere assegnata la percentuale calcolata dell'utente. |
seed |
Valore su cui si basano i calcoli percentuali per percentile. Il calcolo percentuale per un utente specifico sarà lo stesso in tutte le funzionalità se viene usato lo stesso valore seed. Se non viene specificato alcun valore seed, viene creato un valore di inizializzazione predefinito in base al nome della funzionalità. |
Se la funzionalità non è abilitata, il manager delle funzionalità assegna la variante contrassegnata come default_when_disabled all'utente corrente, in questo caso Small.
Se la funzionalità è abilitata, il manager delle funzionalità verifica le allocazioni user, group e percentile in tale ordine al fine di assegnare una variante. Per questo particolare esempio, se l'utente valutato è denominato Marsha nel gruppo denominato Ring1, o se l'utente si trova tra lo 0 e il 10° percentile, la variante specificata viene assegnata all'utente. In questo caso, tutti gli utenti assegnati restituirebbero la variante Big. Se nessuna di queste allocazioni corrisponde, all'utente viene assegnata la variante default_when_enabled, ovvero Small.
La logica di allocazione è simile al filtro di funzionalità Microsoft.Targeting, ma esistono alcuni parametri presenti nella destinazione che non sono nell'allocazione e viceversa. I risultati della destinazione e dell'allocazione non sono correlati.
Override dello stato abilitato con una variante
È possibile usare varianti per eseguire l'override dello stato abilitato di un flag di funzionalità. L'override consente alle varianti la possibilità di estendere la valutazione di un flag di funzionalità. Quando si chiama is_enabled su un flag con varianti, il gestore delle funzionalità verificherà se la variante assegnata all'utente corrente è configurata per eseguire l'override del risultato. Questa operazione viene eseguita usando la proprietà variante facoltativa status_override. Per impostazione predefinita, questa proprietà è impostata su None, il che significa che la variante non influisce sul fatto che il flag sia considerato abilitato o disabilitato. L'impostazione status_override su Enabled consente alla variante, se scelta, di eseguire l'override di un flag da abilitare. L'impostazione status_override su Disabled fornisce la funzionalità opposta, disabilitando quindi il flag quando viene scelta la variante. Non è possibile eseguire l'override di una funzionalità con stato enabled di false.
Se si usa un flag di funzionalità con varianti binarie, la proprietà status_override può essere utile. Consente di continuare a usare API come is_enabled nell'applicazione, sfruttando al tempo stesso le nuove funzionalità fornite con varianti, ad esempio allocazione percentile e seeding.
{
"id": "MyVariantFeatureFlag",
"enabled": true,
"allocation": {
"percentile": [
{
"variant": "On",
"from": 10,
"to": 20
}
],
"default_when_enabled": "Off",
"seed": "Enhanced-Feature-Group"
},
"variants": [
{
"name": "On"
},
{
"name": "Off",
"status_override": "Disabled"
}
]
}
Nell'esempio precedente la funzionalità è sempre abilitata. Se l'utente corrente si trova nell'intervallo percentile calcolato compreso tra 10 e 20, viene restituita la variante On. In caso contrario, viene restituita la variante Off e, poiché status_override è uguale a Disabled, la funzionalità verrà ora considerata disabilitata.
Telemetria
Quando viene distribuita una modifica del flag di funzionalità, è spesso importante analizzarne l'effetto su un'applicazione. Ecco alcune domande che possono verificarsi, ad esempio:
- I flag sono abilitati/disabilitati come previsto?
- Gli utenti di destinazione ottengono l'accesso a una determinata funzionalità come previsto?
- Quale variante viene visualizzata da un utente specifico?
Questi tipi di domande possono essere risposte tramite l'emissione e l'analisi degli eventi di valutazione dei flag di funzionalità. Questa libreria consente facoltativamente a AzureMonitor di produrre dati di telemetria di traccia durante la valutazione del flag di funzionalità tramite OpenTelemetry.
Abilitazione della telemetria
Per impostazione predefinita, i flag di funzionalità non hanno dati di telemetria generati. Per pubblicare i dati di telemetria per un determinato flag di funzionalità, il flag MUST dichiara che è abilitato per l'emissione di dati di telemetria.
Per i flag di funzionalità definiti in JSON, l'abilitazione viene eseguita usando la proprietà telemetry.
{
"feature_management": {
"feature_flags": [
{
"id": "MyFeatureFlag",
"enabled": true,
"telemetry": {
"enabled": true
}
}
]
}
}
Il frammento di codice precedente definisce un flag di funzionalità denominato MyFeatureFlag abilitato per i dati di telemetria. La proprietà telemetry dell'oggetto enabled è impostata su true. Il valore della proprietà enabled deve essere true per pubblicare i dati di telemetria per il flag.
La sezione telemetry di un flag di funzionalità ha le proprietà seguenti:
| Proprietà | Descrizione |
|---|---|
enabled |
Specifica se i dati di telemetria devono essere pubblicati per il flag di funzionalità. |
metadata |
Raccolta di coppie chiave-valore, modellate come dizionario, che possono essere usate per allegare metadati personalizzati relativi al flag di funzionalità agli eventi di valutazione. |
Inoltre, quando si crea FeatureManager, è necessario registrare un callback per gestire gli eventi di telemetria. Questo callback viene chiamato ogni volta che viene valutato un flag di funzionalità e la telemetria è abilitata per tale flag.
feature_manager = FeatureManager(feature_flags, on_feature_evaluated=publish_telemetry)
Application Insights Telemetry
La libreria di gestione di funzionalità fornisce un server di pubblicazione di telemetria predefinito che invia i dati di valutazione dei flag di funzionalità ad Application Insights. Per abilitare Application Insights, è possibile installare la libreria di gestione delle funzionalità con Monitoraggio di Azure tramite pip install FeatureManagement[AzureMonitor]. Questo comando installa il pacchetto azure-monitor-events-extension, usato per applicare lo stile dei dati di telemetria ad Application Insights usando OpenTelemetry.
Nota
Il pacchetto azure-monitor-events-extension aggiunge solo i dati di telemetria alla pipeline Open Telemetry. La registrazione di Application Insights è ancora necessaria.
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor(
connection_string="InstrumentationKey=00000000-0000-0000-0000-000000000000"
)
Pubblicazione di telemetria personalizzata
Poiché il callback dei dati di telemetria è una funzione, può essere personalizzato per pubblicare i dati di telemetria in qualsiasi destinazione desiderata. Ad esempio, i dati di telemetria possono essere pubblicati in un servizio di registrazione, in un database o in un servizio di telemetria personalizzato.
Quando viene valutato un flag di funzionalità e la telemetria è abilitata, il manager delle funzionalità chiama il callback dei dati di telemetria con un parametro EvaluationEvent.
EvaluationEvent contiene le proprietà seguenti:
| Tag | Descrizione |
|---|---|
feature |
Il flag di funzionalità usato. |
user |
ID utente usato per la destinazione. |
enabled |
Indica se il flag di funzionalità viene valutato come abilitato. |
Variant |
Variante assegnata. |
VariantAssignmentReason |
Motivo per cui viene assegnata la variante. |
Passaggi successivi
Per informazioni su come usare i flag di funzionalità nelle applicazioni, continuare con gli avvi rapidi.
Per informazioni su come usare i filtri di funzionalità, continuare con le esercitazioni seguenti.