Configurer les tests et les tests A/B à l'aide de flags de fonctionnalité

Les allocations de flags de fonctionnalité App Lifecycle Manager vous aident à tester votre application en répartissant les pourcentages de trafic. Ainsi, certains de vos utilisateurs voient une variante de votre application, tandis que d'autres en voient une autre. Vous pouvez ainsi déterminer quelles variantes ou fonctionnalités sont les plus efficaces (ce processus est souvent appelé test A/B). Les allocations de flags de fonctionnalité vous aident à définir comment répartir votre trafic et à intégrer les variantes allouées à votre application.

Ce guide vous explique comment définir des variantes, configurer la répartition du trafic et intégrer des variantes à votre application.

Pour simplifier le suivi et l'analyse, vous devez attribuer des ID de chaîne descriptifs à vos variantes (par exemple, "experimental" et "baseline") et utiliser ces noms directement dans votre code et vos pipelines d'analyse.

Prérequis

À vérifier avant de commencer :

  1. Vous avez suivi le guide de démarrage rapide Déployer des flags de fonctionnalité ou Utiliser des flags de fonctionnalité (guide de démarrage rapide autonome).
  2. Vous disposez d'un environnement Google Cloud CLI configuré pour gérer les ressources App Lifecycle Manager.

Configurer une allocation de flag de fonctionnalité

Pour configurer un flag de fonctionnalité expérimentale :

  1. Définissez l'attribut aléatoire (par exemple, userID) qui sera utilisé pour le bucketing persistant afin de garantir une expérience cohérente pour chaque utilisateur.

      gcloud beta app-lifecycle-manager flags attributes create "user-id-attr" \
      --key="userID" \
      --attribute-value-type="STRING" \
      --location=global

  2. Utilisez une allocation pour définir la répartition (50/50, par exemple) en référençant vos ID de variante descriptifs.

    # Create a flag with explicitly named variants for the experiment and a 50/50 allocation referencing the custom IDs
gcloud beta app-lifecycle-manager flags create "search-algo-test" \
  --key="search-algo-test" \
  --flag-value-type=BOOL \
  --location="global" \
  --unit-kind="demo-test-unitkind" \
  --variants='[
      {
      "id": "experimental",
      "booleanValue": true
      },
      {
      "id": "baseline",
      "booleanValue": false
      }
  ]'\
  --evaluation-spec='{
      "allocations": [{
          "id": "search-split-50-50",
          "randomizedOn": "userID",
          "slots": [
          {"variant": "baseline", "weight": 50},
          {"variant": "experimental", "weight": 50}
          ]
      }],
      "defaultTarget": "search-split-50-50",
      "attributes": ["projects/PROJECT_ID/locations/global/flagAttributes/user-id-attr"]
  }'

  3. Dans votre service de backend, initialisez le SDK OpenFeature et injectez le userID dans le contexte d'évaluation. Utilisez la méthode BooleanValueDetails (ou l'équivalent pour votre langage) pour récupérer le variantID (chaîne) dans votre application. Vous pouvez ainsi modifier la logique de votre backend en fonction du nom descriptif plutôt que d'une simple valeur booléenne.

    // 1. Prepare evaluation context
evalCtx := map[string]any{"userID": currentUser.ID}

// 2. Fetch evaluation details to get the variant name
details, err := client.BooleanValueDetails(ctx, "search-algo-test", false, evalCtx)

// 3. Execute logic based on the Variant ID (string name)
if details.Variant == "experimental" {
    results = search.ExperimentalV2(query)
} else {
    results = search.BaselineV1(query)
}

  4. Utilisez des noms de variantes descriptifs pour que votre audit et votre analyse génèrent automatiquement de la documentation. Pour auditer les évaluations, enregistrez la chaîne details.Variant avec vos métriques de performances :

     startTime := time.Now()
 // ... perform search ...
 duration := time.Since(startTime)

 // Audit: Log the descriptive variant name ("experimental" or "baseline")
 logger.Info("Search performed",
    "variant", details.Variant,
    "latency_ms", duration.Milliseconds(),
 )

    En comparant les métriques du groupe "Experimental" à celles du groupe "Baseline", vous pouvez analyser manuellement si le nouvel algorithme améliore l'efficacité du backend ou la pertinence de la recherche avant de procéder à un déploiement complet.

Étape suivante

  • Découvrez comment résoudre les problèmes .