Vue d’ensemble

Les Datadog Feature Flags pour les applications côté serveur vous permettent de contrôler à distance la disponibilité des fonctionnalités, d’exécuter des expériences et de déployer de nouvelles fonctionnalités en toute confiance. Les SDK côté serveur reçoivent la configuration des Feature Flags et les évaluent localement. Certains SDK utilisent un traceur Datadog pour la distribution de la configuration ou la télémétrie.

Les Datadog Feature Flags sont basés sur le standard OpenFeature, une spécification open source et indépendante du fournisseur pour les API des Feature Flags. Si vous découvrez les concepts OpenFeature tels que les fournisseurs, le contexte d’évaluation et les hooks, consultez la documentation sur les concepts OpenFeature.

Distribution de la configuration

La distribution de la configuration agentless est la valeur par défaut dans les versions du SDK serveur qui la prennent en charge. Le SDK récupère la configuration des Feature Flags directement depuis le CDN géré par Datadog via HTTPS, puis évalue les Feature Flags localement. Un Datadog Agent n’est pas requis pour la configuration des Feature Flags.

La source par défaut n’active pas le trafic des Feature Flags pour chaque installation de traceur. L’interrogation agentless ne commence que lorsque le code de l’application initialise ou accède au fournisseur OpenFeature de Datadog. La sélection explicite de remote_config active l’abonnement à Feature Flags Remote Configuration. Les requêtes provenant de l’une ou l’autre source contribuent à la facturation des Feature Flags du serveur.

La distribution par CDN pour Java nécessite dd-openfeature et dd-java-agent. Elle ne nécessite pas de Datadog Agent pour la configuration des Feature Flags.

La distribution agentless est disponible pour les SDK et les versions répertoriés. Les autres SDK serveur utilisent la Agent Remote Configuration.

Choisir une langue

Sélectionnez votre langue ou votre framework pour afficher les instructions de configuration spécifiques au SDK :

Pour les environnements d’exécution serverless, consultez Environnements serverless pour la configuration agentless, les exigences de version et les limitations initiales de télémétrie.

Prérequis

Les exigences dépendent du SDK sélectionné et de la source de configuration. Les exigences standard incluent :

• Les versions du traceur spécifique au langage ou du fournisseur OpenFeature répertoriées sur la page du SDK
• Une [clé d’API] Datadog2

La distribution CDN Java nécessite l’agent Java dans le processus d’application. Elle ne nécessite pas de traçage APM ni de service Datadog Agent distinct.

Les exigences spécifiques à la source sont :

Configuration agentless

Sur une version de SDK prise en charge, configurez le processus d’application :

# Required for direct configuration delivery
DD_API_KEY=<DATADOG_API_KEY>
DD_SITE=<code class="js-region-param region-param" data-region-param="dd_site"></code>
DD_ENV=<YOUR_ENVIRONMENT>

Aucune activation de Feature Flags ni aucun paramètre de source n’est requis. Consultez Java Feature Flags, Node.js Feature Flags ou Python Feature Flags pour les versions de dépendances et l’initialisation spécifique au langage. L’initialisation ou l’accès au fournisseur démarre l’interrogation CDN ; l’installation et l’initialisation du traceur seules ne le font pas.

Agent Remote Configuration

Pour Java, Node.js et Python, définissez explicitement la source pour conserver la distribution gérée par l’Agent :

DD_FEATURE_FLAGS_CONFIGURATION_SOURCE=remote_config

La Remote Configuration est activée par défaut dans l’Agent 7.47.0 et versions ultérieures. Si votre Agent a la Remote Configuration désactivée, réactivez-la en définissant DD_REMOTE_CONFIGURATION_ENABLED=true ou en ajoutant remote_configuration.enabled: true à votre datadog.yaml.

Consultez la documentation sur la Remote Configuration pour obtenir des instructions de configuration détaillées pour les environnements de déploiement.

Les implémentations Java, Node.js et Python existantes avec DD_EXPERIMENTAL_FLAGGING_PROVIDER_ENABLED=true restent sur la Remote Configuration pendant une fenêtre de migration. Ce paramètre est obsolète. Consultez Migrer depuis le paramètre de fournisseur hérité pour rester explicitement sur la Remote Configuration ou passer à une livraison agentless.

Intervalle d’interrogation de la Remote Configuration

L’agent interroge Datadog pour obtenir des mises à jour de configuration à un intervalle configurable :

# Optional: Configure the Agent polling interval (default: 60s)
DD_REMOTE_CONFIGURATION_REFRESH_INTERVAL=10s

Configuration avancée de l’application

Configurez votre application avec les variables d’environnement Datadog standard : Celles-ci sont communes à tous les SDK côté serveur :

# Required: Service identification
DD_SERVICE=<YOUR_SERVICE_NAME>
DD_ENV=<YOUR_ENVIRONMENT>
DD_VERSION=<YOUR_APP_VERSION>

# Optional: Disable Feature Flags and both delivery paths
# DD_FEATURE_FLAGS_ENABLED=false

# Optional: Enable flag evaluation metrics
# See "Set Up Server-Side Flag Evaluation Metrics" documentation

Pour les SDK et les modes de livraison qui le prennent en charge, consultez Configurer les métriques d’évaluation des Feature Flags pour activer la feature_flag.evaluations métrique. Les versions initiales agentless pour Node.js n’exportent pas de métriques d’évaluation ni d’événements d’exposition. Java et Python nécessitent un Datadog Agent pris en charge ou un chemin de télémétrie serverless pour exporter ces signaux. Consultez Feature Flag Graphs pour plus d’informations sur les graphiques disponibles. Consultez Set Up APM Trace Enrichment for Feature Flags pour joindre les données d’évaluation des Feature Flags aux traces APM à des fins de filtrage et d’expérimentation.

Tests avec des fournisseurs en mémoire

Datadog prend en charge ces approches de test :

• Tests d’intégration : pointez DatadogProvider vers un environnement de test dédié et contrôlez les valeurs des Feature Flags depuis l’interface utilisateur de Datadog. Cela permet d’exercer le fournisseur réel et la source de configuration sélectionnée de bout en bout.
• Tests unitaires : remplacez DatadogProvider par le InMemoryProvider standard d’OpenFeature (ou un stub de test équivalent, lorsqu’aucun fournisseur en mémoire n’est disponible dans le langage) et définissez les valeurs des Feature Flags directement dans le code de test. Cela permet de garder les tests hermétiques et hors ligne.

Cette section couvre l’approche en mémoire. Comme l’API OpenFeature est conçue pour rendre les fournisseurs interchangeables au moment de l’exécution, votre code d’application ne change pas — seul le fournisseur enregistré lors de la configuration du test change.

Un test typique suit ce modèle :

1. Créez une map des clés de Feature Flags vers les variantes dans votre configuration de test.
2. Enregistrez un InMemoryProvider avec cette map via l’API OpenFeature.
3. Appelez le client OpenFeature dans les unités testées. Le InMemoryProvider renvoie les attributions de Feature Flags configurées lors de la configuration du test.
4. Réinitialisez le fournisseur lors du nettoyage du test pour éviter toute fuite d’état entre les tests.

Consultez la page du SDK de votre langage (sélectionnez-la en haut de cette page) pour obtenir un exemple de test concret.

Exigences relatives aux attributs de contexte

Utilisez des attributs plats dans votre contexte d’évaluation :

const evaluationContext = {
  targetingKey: req.session?.userID,
  companyId: req.session?.companyID,
  tier: 'enterprise'
};

const value = client.getBooleanValue('my-flag', false, evaluationContext);

Évitez les objets et les tableaux imbriqués :

// These attributes will cause exposure events to be dropped
const evaluationContext = {
  targetingKey: req.session?.userID,
  company: { id: req.session?.companyID },  // nested object - NOT SUPPORTED
  roles: ['admin', 'user']                   // array - NOT SUPPORTED
};

Lectures complémentaires

Pour les déploiements basés sur des pourcentages et le partitionnement déterministe, consultez Répartition et randomisation du trafic.

Documentation, liens et articles supplémentaires utiles:

Feature Flags côté clientDOCUMENTATION Remote ConfigurationDOCUMENTATION Configurer les métriques d'évaluation des Feature Flags côté serveurGUIDE Graphiques des Feature FlagsCONCEPT Environnements serverless et Feature FlagsDOCUMENTATION Sources de configuration du SDK serveurCONCEPT Configurer l'enrichissement des traces APM pour les Feature FlagsGUIDE