Zu Funktionsverwaltung gehen

Die Go-Featureverwaltungsbibliothek bietet eine Möglichkeit, Anwendungsfunktionen basierend auf Featurekennzeichnungen zu entwickeln und verfügbar zu machen. Sobald ein neues Feature entwickelt wurde, haben viele Anwendungen spezielle Anforderungen, z. B. wann das Feature aktiviert werden soll und unter welchen Bedingungen. Diese Bibliothek bietet eine Möglichkeit, diese Beziehungen zu definieren und auch in gängige Go-Codemuster zu integrieren, um diese Features verfügbar zu machen.

Featurekennzeichnungen bieten eine Möglichkeit für Go-Anwendungen, Features dynamisch zu aktivieren oder zu deaktivieren. Entwickler können Featureflags in einfachen Anwendungsfällen wie Bedingungsanweisungen verwenden.

Hier sind einige der Vorteile der Verwendung der Go-Feature-Management-Bibliothek:

• Eine allgemeine Konvention für die Featureverwaltung
• Niedrige Einstiegsbarriere
  • Featurekennzeichnungsquelle für Azure-App-Konfiguration
• Verwaltung des Lebenszyklus von Feature Flags
  • Konfigurationswerte können sich in Echtzeit ändern
• Behandlung einfacher bis komplexer Szenarien
  • Funktionen aktivieren/deaktivieren
  • Dynamische Auswertung des Funktionsstatus basierend auf dem Aufruf an den Server

Die Go-Featureverwaltungsbibliothek ist Open Source. Weitere Informationen finden Sie im GitHub-Repository.

Featureflags

Featureflags können aktiviert oder deaktiviert werden. Der Status eines Flags kann durch die Verwendung von Featurefiltern als bedingt festgelegt werden.

Feature-Filter

Featurefilter definieren ein Szenario, für das ein Feature aktiviert werden soll. Wenn ein Feature ausgewertet wird, egal ob es aktiviert oder deaktiviert ist, wird die Liste der Featurefilter durchlaufen, bis einer der Filter entscheidet, dass das Feature aktiviert werden soll. An diesem Punkt gilt das Feature als aktiviert, und der Durchlauf der Featurefilter endet. Wenn kein Featurefilter angibt, dass das Feature aktiviert werden soll, gilt es als deaktiviert.

Beispielsweise könnte ein Microsoft Edge-Browserfeaturefilter entworfen werden. Dieser Featurefilter aktiviert alle daran angefügten Features, solange eine HTTP-Anforderung von Microsoft Edge stammt.

Featureflagkonfiguration

Die Go-Featureverwaltung unterstützt die Verwendung von Featurekennzeichnungen, die in der Azure-App-Konfiguration durch den integrierten Featurekennzeichnungsanbieter azappconfigdefiniert sind, sowie einen Erweiterbarkeitspunkt über die FeatureFlagProvider Schnittstelle, um Featurekennzeichnungen zu nutzen, die von anderen Anbietern definiert sind.

import (
    "context"
    "log"

    "github.com/Azure/AppConfiguration-GoProvider/azureappconfiguration"
    "github.com/microsoft/Featuremanagement-Go/featuremanagement"
    "github.com/microsoft/Featuremanagement-Go/featuremanagement/providers/azappconfig"
)


// ... ...
// Load Azure App Configuration
appConfig, err := azureappconfiguration.Load(ctx, authOptions, options)
if err != nil {
    log.Fatalf("Failed to load configuration: %v", err)
}


// Create feature flag provider
featureFlagProvider, err := azappconfig.NewFeatureFlagProvider(appConfig)
if err != nil {
    log.Fatalf("Error creating feature flag provider: %v", err)
}

// Create feature manager
featureManager, err := featuremanagement.NewFeatureManager(featureFlagProvider, nil)
if err != nil {
    log.Fatalf("Error creating feature manager: %v", err)
}

Featureflagdeklaration

Das folgende Beispiel zeigt das Format, das zum Einrichten von Featureflags in einer JSON-Datei verwendet wird.

{
    "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"
                            }
                        }
                    ]
                }
            }
        ]
    }
}

Der feature_management Abschnitt des JSON-Dokuments wird konventionsspezifisch zum Laden von Featurekennzeichnungseinstellungen verwendet. Featurekennzeichnungsobjekte müssen im feature_flags-Array unter dem feature_management-Abschnitt aufgeführt werden.

Im Abschnitt oben sehen wir drei verschiedene Features. Eine Featurekennzeichnung hat id- und enabled-Eigenschaften. Der id ist der Name, der zum Identifizieren und Verweisen auf die Featurekennzeichnung verwendet wird. Die enabled-Eigenschaft gibt den aktivierten Status der Featurekennzeichnung an. Ein Feature ist OFF, wenn "false" aktiviert ist. Ist enabled "true", hängt der Status des Features von den Bedingungen ab. Wenn keine Bedingungen vorhanden sind, ist das Feature "EIN". Wenn Bedingungen vorhanden sind und sie erfüllt sind, ist das Feature "EIN". Wenn Bedingungen vorhanden sind und sie nicht erfüllt sind, ist das Feature DEAKTIVIERT. Die Conditions-Eigenschaft deklariert die Bedingungen, die zum dynamischen Aktivieren des Features verwendet werden. Features definieren ihre Featurefilter im client_filters Array. FeatureV gibt einen Featurefilter mit dem Namen Microsoft.TimeWindow an. Dieser Filter ist ein Beispiel für einen konfigurierbaren Featurefilter. Wir können im Beispiel sehen, dass der Filter über eine Parameters-Eigenschaft verfügt. Diese Eigenschaft wird verwendet, um den Filter zu konfigurieren. In diesem Fall werden die Start- und Endzeiten für das zu aktive Feature konfiguriert.

Das detaillierte Schema des feature_management-Abschnitts finden Sie hier.

Erweitert: Die Verwendung des Doppelpunkts ":" ist in Featurekennzeichnungsnamen verboten.

On/Off-Deklaration

Der folgende Codeausschnitt veranschaulicht eine alternative Möglichkeit zum Definieren eines Features für einfache Ein-/Aus-Features.

{
    "feature_management": {
        "feature_flags": [
            {
                "id": "FeatureT",
                "enabled": "true"
            },
            {
                "id": "FeatureX",
                "enabled": "false"
            }
        ]
    }
}

Anforderungstyp

Die requirement_type-Eigenschaft einer Featurekennzeichnung wird verwendet, um zu bestimmen, ob die Filter Any- oder All-Logik zum Auswerten des Status eines Features verwenden sollen. Wenn requirement_type nicht angegeben ist, wird der Standardwert Any.

• Any bedeutet, dass nur ein Filter als „true“ ausgewertet werden muss, damit das Feature aktiviert wird.
• All bedeutet, dass jeder Filter als „true“ ausgewertet werden muss, damit das Feature aktiviert wird.

Der Anforderungstyp (requirement_type) All ändert den Durchlauf. Wenn keine Filter vorhanden sind, ist das Feature deaktiviert. Anschließend werden die Featurefilter durchlaufen, bis einer der Filter entscheidet, dass das Feature deaktiviert werden soll. Wenn kein Filter angibt, dass das Feature deaktiviert werden soll, wird es als aktiviert betrachtet.

{
    "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"
                            }
                        }
                    ]
                }
            },
        ]
    }
}

Im obigen Beispiel gibt FeatureW eine requirement_type von All an, was bedeutet, dass alle Filter als „true“ ausgewertet werden müssen, damit das Feature aktiviert werden kann. In diesem Fall ist das Feature für 50 % der Benutzer im angegebenen Zeitfenster aktiviert.

Consumption

Die grundlegende Form der Featureverwaltung überprüft, ob eine Featurekennzeichnung aktiviert ist und führt dann Aktionen basierend auf dem Ergebnis aus. Der Status eines Feature-Flags wird über die Methode FeatureManager von IsEnabled überprüft.

// Create feature flag provider
featureFlagProvider, err := azappconfig.NewFeatureFlagProvider(appConfig)
if err != nil {
    log.Fatalf("Error creating feature flag provider: %v", err)
}

// Create feature manager
featureManager, err := featuremanagement.NewFeatureManager(featureFlagProvider, nil)
if err != nil {
    log.Fatalf("Error creating feature manager: %v", err)
}

// Check if feature is enabled
enabled, err := featureManager.IsEnabled("FeatureX")
if err != nil {
    log.Printf("Error checking feature: %v", err)
    return
}

if enabled {
    // Do something
}

Implementieren eines Featurefilters

Das Erstellen eines Featurefilters bietet eine Möglichkeit, Features basierend auf von Ihnen definierten Kriterien zu aktivieren. Um einen Featurefilter zu implementieren, muss die FeatureFilter-Schnittstelle implementiert werden. FeatureFilter hat eine Methode mit dem Namen Evaluate. Wenn ein Feature einem Filter zugeordnet ist, wird die Methode während der Evaluate Auswertung aufgerufen. Wenn Evaluatetrue zurückgibt, wird die Funktion als aktiviert betrachtet.

type FeatureFilter interface {
	// Name returns the identifier for this filter
	Name() string

	// Evaluate determines whether a feature should be enabled based on the provided contexts
	Evaluate(evalCtx FeatureFilterEvaluationContext, appCtx any) (bool, error)
}

type FeatureFilterEvaluationContext struct {
	// FeatureName is the name of the feature being evaluated
	FeatureName string

	// Parameters contains the filter-specific configuration parameters
	Parameters map[string]any
}

Der folgende Codeausschnitt veranschaulicht, wie ein angepasster Featurefilter implementiert wird.

type MyCustomFilter struct{}

func (f *MyCustomFilter) Evaluate(ctx context.Context, context *FeatureFilterEvaluationContext) bool {
    // Custom logic to determine if feature should be enabled
    if satisfyCriteria() {
        return true
    }
    return false
}

func (f *MyCustomFilter) Name() string {
    return "MyCustomFilter"
}

Featurefilter werden registriert, indem sie beim Erstellen des FeatureManager angegeben werden. Wenn ein benutzerdefinierter Featurefilter Kontext benötigt, können sie über den FeatureFilterEvaluationContext Parameter übergeben werden.

// Register custom filters
options := &featuremanagement.Options{
    Filters: []featuremanagement.FeatureFilter{
        &MyCustomFilter{},
    },
}

// Create feature manager with custom filters
featureManager, err := featuremanagement.NewFeatureManager(featureFlagProvider, options)
if err != nil {
    log.Fatalf("Error creating feature manager: %v", err)
}

Filteraliasattribut

Wenn ein Feature-Filter für einen Feature-Flag registriert ist, wird sein Name als Standardalias verwendet. Sie können diesen Bezeichner überschreiben, indem Sie die Name() Methode implementieren, die den Namen angibt, der in der Konfiguration verwendet werden soll, wenn sie auf den Filter innerhalb eines Featurekennzeichens verweisen.

Fehlende Filter für Funktionen

Wenn ein Feature für einen bestimmten Featurefilter aktiviert ist und dieser Featurefilter nicht registriert ist, wird ein Fehler zurückgegeben, wenn das Feature ausgewertet wird.

Integrierte Funktionsfilter

Es gibt zwei Featurefilter, die im featuremanagement Paket enthalten sind: TimeWindowFilterund TargetingFilter.

Jeder der integrierten Featurefilter verfügt über eigene Parameter. Hier ist die Liste der Featurefilter zusammen mit Beispielen.

Microsoft.TimeWindow

Dieser Filter bietet die Möglichkeit, ein Feature basierend auf einem Zeitfenster zu aktivieren. Wenn nur End angegeben ist, wird die Funktion bis zu diesem Zeitpunkt als eingeschaltet angesehen. Wenn nur Start angegeben ist, wird das Feature ab diesem Zeitpunkt als aktiv angesehen.

"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

Dieser Filter bietet die Möglichkeit, ein Feature für eine Zielgruppe zu aktivieren. Eine ausführliche Erläuterung der Zielbestimmung wird im folgenden Abschnitt zur Zielbestimmung erläutert. Die Filterparameter enthalten ein Audience-Objekt, das Benutzer, Gruppen, ausgeschlossene Benutzer/Gruppen und einen Standardprozentsatz der Benutzerbasis beschreibt, die Zugriff auf das Feature haben sollen. Jedes Gruppenobjekt, das im Groups-Abschnitt aufgeführt ist, muss auch angeben, welcher Prozentsatz der Mitglieder der Gruppe Zugriff haben soll. Wenn ein Benutzer im Exclusion-Abschnitt angegeben wird, entweder direkt oder wenn sich der Benutzer in einer ausgeschlossenen Gruppe befindet, ist das Feature deaktiviert. Andernfalls gilt Folgendes: Wenn Benutzende direkt im Users-Abschnitt angegeben werden oder wenn die Benutzenden im Prozentsatz einer der Gruppenrollouts enthalten sind oder wenn die Benutzenden in den Prozentsatz des Standardrollouts fällt, wird das Feature für diese Benutzenden aktiviert.

"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"
                    ]
                }
            }
        }
    }
]

Zielbestimmung

Die Zielbestimmung ist eine Featureverwaltungsstrategie, mit der Entwickler neue Features schrittweise für ihre Benutzerbasis bereitstellen können. Die Strategie basiert auf dem Konzept der Zielgruppenadressierung einer Gruppe von Benutzern, die als Zielgruppe bezeichnet werden. Eine Benutzergruppe besteht aus bestimmten Benutzern, Gruppen, ausgeschlossenen Benutzern/Gruppen und einem bestimmten Prozentsatz der gesamten Benutzerbasis. Die Gruppen, die in der Zielgruppe enthalten sind, können weiter in Prozentsätze ihrer Gesamtmitglieder unterteilt werden.

Die folgenden Schritte veranschaulichen ein Beispiel für ein progressives Rollout für ein neues Feature „Beta“:

1. Individuelle Benutzer Jeff und Alicia erhalten Zugriff auf die Betaversion.
2. Ein anderer Benutzer, Mark, fordert die Anmeldung an und wird aufgenommen.
3. Zwanzig Prozent einer Gruppe, die als „Ring1“-Benutzer bezeichnet wird, sind in der Betaversion enthalten.
4. Die Anzahl der in der Betaversion enthaltenen „Ring1“-Benutzende wird auf 100 Prozent erhöht.
5. Fünf Prozent der Benutzerbasis werden in die Beta einbezogen.
6. Der Rollout-Prozentsatz wird auf 100 Prozent erhöht, und das Feature wird vollständig eingeführt.

Diese Strategie für den Rollout eines Features ist über den enthaltenen Microsoft.Targeting-Featurefilter in die Bibliothek integriert.

Zielgruppenspezifische Ansprache eines Benutzers

Der Zielfilter basiert auf einem Zielkontext, um zu bewerten, ob ein Feature aktiviert werden soll. Dieser Zielkontext enthält Informationen, z. B. die aktuell ausgewertete benutzende Person und zu welchen Gruppen sie gehört. Der Zielkontext muss direkt übergeben werden, wenn IsEnabledWithAppContext aufgerufen wird.

// ... ...
// Create targeting context
targetingCtx := featuremanagement.TargetingContext{
    UserID: "test_user",
    Groups: []string{"Ring1"},
}

// Check if feature is enabled for the user
enabled, err := featureManager.IsEnabledWithAppContext("Beta", targetingCtx)
if err != nil {
    log.Printf("Error checking feature: %v", err)
    return
}

if enabled {
    // Feature is enabled for this user
}

Zielausschluss

Beim Definieren einer Zielgruppe können Benutzer und Gruppen von der Zielgruppe ausgeschlossen werden. Ausschlüsse sind nützlich, wenn ein Feature für eine Gruppe von Benutzern eingeführt wird, aber einige Benutzer oder Gruppen aus dem Rollout ausgeschlossen werden müssen. Der Ausschluss wird durch Hinzufügen einer Liste von Benutzern und Gruppen zur Exclusion-Eigenschaft der Benutzergruppe definiert.

"Audience": {
    "Users": [
        "Jeff",
        "Alicia"
    ],
    "Groups": [
        {
            "Name": "Ring0",
            "RolloutPercentage": 100
        }
    ],
    "DefaultRolloutPercentage": 0,
    "Exclusion": {
        "Users": [
            "Mark"
        ]
    }
}

Im obigen Beispiel ist das Feature für Benutzer mit dem Namen Jeff und Alicia aktiviert. Es ist auch für Benutzer in der Gruppe mit dem Namen Ring0 aktiviert. Wenn der Benutzer jedoch Mark benannt ist, ist das Feature deaktiviert, unabhängig davon, ob er sich in der Gruppe Ring0 befindet oder nicht. Ausschlüsse haben Vorrang vor dem Rest des Zielfilters.

Varianten

Wenn einer Anwendung neue Features hinzugefügt werden, kann es vorkommen, dass ein Feature über mehrere verschiedene vorgeschlagene Entwurfsoptionen verfügt. Eine gängige Lösung für die Entscheidung für ein Design ist eine Form von A/B-Tests. A/B-Tests umfassen die Bereitstellung einer anderen Version des Features für verschiedene Segmente der Benutzerbasis und die Auswahl einer Version basierend auf der Benutzerinteraktion. In dieser Bibliothek wird diese Funktionalität aktiviert, indem verschiedene Konfigurationen eines Features mit Varianten dargestellt werden.

Varianten ermöglichen es einer Feature-Flag, mehr als nur eine einfache Ein/Aus-Option zu sein. Eine Variante stellt einen Wert einer Featurekennzeichnung dar, die eine Zeichenfolge, eine Zahl, ein boolescher Wert oder sogar ein Konfigurationsobjekt sein kann. Ein Featureflag, das Varianten deklariert, sollte definieren, unter welchen Umständen jede Variante verwendet werden soll, was im Abschnitt Zuweisen von Varianten ausführlicher behandelt wird.

type Variant struct {
	// Name uniquely identifies this variant
	Name string

	// ConfigurationValue holds the value for this variant
	ConfigurationValue any
}

Abrufen von Varianten

Für jedes Feature kann eine Variante mithilfe der FeatureManager-Methode von GetVariant abgerufen werden. Die Zuweisung der Variante hängt von dem Benutzer ab, der momentan ausgewertet wird, und diese Informationen werden aus dem übergebenen Zielkontext abgerufen.

targetingCtx := featuremanagement.TargetingContext{
    UserID: "Adam",
}

variant, err := featureManager.GetVariant("TestVariants", targetingCtx)
if err != nil {
    log.Printf("Error getting variant: %v", err)
    return
}

if variant != nil {
    variantConfiguration := variant.Configuration

    // Do something with the resulting variant and its configuration
}

Deklaration von Variantenfeatureflags

Im Vergleich zu normalen Featureflags weisen Variantenfeatureflags zwei zusätzliche Eigenschaften auf: variants und allocation. Die variants-Eigenschaft ist ein Array, das die für dieses Feature definierten Varianten enthält. Die allocation-Eigenschaft definiert, wie diese Varianten für das Feature zugewiesen werden sollen. Genau wie beim Deklarieren normaler Featureflags können Sie Varianten-Featureflags in einer JSON-Datei einrichten. Hier sehen Sie ein Beispiel für ein Variantenfeatureflag.

{
    "feature_management": {
        "feature_flags": [
            {
                "id": "MyVariantFeatureFlag",
                "enabled": true,
                "allocation": {
                    "default_when_enabled": "Small",
                    "group": [
                        {
                            "variant": "Big",
                            "groups": [
                                "Ring1"
                            ]
                        }
                    ]
                },
                "variants": [
                    { 
                        "name": "Big"
                    },  
                    { 
                        "name": "Small"
                    } 
                ]
            }
        ]
    }
}

Definieren von Varianten

Jede Variante verfügt über zwei Eigenschaften: einen Namen und eine Konfiguration. Der Name wird verwendet, um auf eine bestimmte Variante zu verweisen, und die Konfiguration ist der Wert dieser Variante. Die Konfiguration kann mithilfe der Eigenschaft configuration_value festgelegt werden. configuration_value ist eine Inlinekonfiguration, die ein Zeichenfolgen-, Zahlen-, boolesches oder Konfigurationsobjekt sein kann. Wenn configuration_value nicht angegeben wird, ist die Eigenschaft Configuration der zurückgegebenen Variante nil.

Für jedes Feature unter der variants-Eigenschaft wird eine Liste aller möglichen Varianten definiert.

{
    "feature_management": {
        "feature_flags": [
            {
                "id": "MyVariantFeatureFlag",
                "variants": [
                    { 
                        "name": "Big", 
                        "configuration_value": {
                            "Size": 500
                        }
                    },  
                    { 
                        "name": "Small", 
                        "configuration_value": {
                            "Size": 300
                        }
                    } 
                ]
            }
        ]
    }
}

Zuweisen von Varianten

Der Prozess der Zuordnung der Varianten eines Features wird durch die allocation-Eigenschaft des Features bestimmt.

"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"
    } 
]

Die allocation-Einstellung eines Features weist die folgenden Eigenschaften auf:

Wenn das Feature nicht aktiviert ist, weist der Feature-Manager dem aktuellen Benutzer die als default_when_disabled markierte Variante zu, die in diesem Fall Small ist.

Wenn das Feature aktiviert ist, prüft der Feature-Manager die Zuweisungen von user, group und percentile in dieser Reihenfolge, um eine Variante zuzuweisen. Wenn der ausgewertete Benutzer Marsha heißt, zur Gruppe Ring1 gehört oder der Benutzer in das Perzentil zwischen 0 und 10 fällt, wird dem Benutzer die angegebene Variante zugewiesen. In diesem Fall würden alle zugewiesenen Benutzer die Variante Big zurückgeben. Wenn keine dieser Zuordnungen übereinstimmt, wird dem Benutzer die default_when_enabled-Variante zugewiesen, die Small ist.

Die Zuordnungslogik ähnelt dem Microsoft.Targeting-Featurefilter, aber es gibt einige Parameter, die in der Zielbestimmung vorhanden sind, die nicht in der Zuordnung enthalten sind, und umgekehrt. Die Ziel- und Zuordnungsergebnisse hängen nicht zusammen.

Überschreiben des aktivierten Zustands mit einer Variante

Sie können Varianten verwenden, um den aktivierten Status einer Featurekennzeichnung außer Kraft zu setzen. Die Überschreibung bietet Varianten die Möglichkeit, die Auswertung eines Featureflags zu erweitern. Wenn IsEnabledWithAppContext bei einem Flag mit Varianten aufgerufen wird, überprüft der Featureverwalter, ob die dem aktuellen Benutzer zugewiesene Variante so konfiguriert ist, dass sie das Ergebnis überschreibt. Die Überschreibung erfolgt mithilfe der optionalen Varianteneigenschaft status_override. Diese Eigenschaft ist standardmäßig auf None festgelegt, was bedeutet, dass die Variante keine Auswirkungen darauf hat, ob die Kennzeichnung als aktiviert oder deaktiviert gilt. Wenn Sie status_override auf Enabled festlegen, kann die Variante bei Auswahl eine zu aktivierende Kennzeichnung außer Kraft setzen. Das Festlegen von status_override auf Disabled bietet die entgegengesetzte Funktionalität, wodurch die Kennzeichnung deaktiviert wird, wenn die Variante ausgewählt wird. Ein Feature mit einem enabled-Status von false kann nicht außer Kraft gesetzt werden.

Wenn Sie ein Featureflag mit binären Varianten verwenden, kann die status_override-Eigenschaft hilfreich sein. Sie können APIs wie IsEnabledaWithAppContext in Ihrer Anwendung weiterhin verwenden, während Sie von den neuen Features profitieren, die mit Varianten einhergehen, z. B. Perzentilzuweisung und Seed.

{
    "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"
        }
    ]
}

Im obigen Beispiel ist das Feature immer aktiviert. Wenn sich der aktuelle Benutzer im berechneten Quantilbereich von 10 bis 20 befindet, wird die On-Variante zurückgegeben. Andernfalls wird die Off-Variante zurückgegeben und da status_override gleich Disabled ist, wird das Feature jetzt als deaktiviert betrachtet.

Nächste Schritte

Fahren Sie mit den folgenden Schnellstarts fort, um zu erfahren, wie Featureflags in Ihren Anwendungen verwendet werden.

Wenn Sie mehr über die Verwendung von Featurefiltern erfahren möchten, fahren Sie mit den folgenden Tutorials fort.