aiconfig-projects

Par launchdarkly · agent-skills

Guide de configuration des projets LaunchDarkly dans votre codebase. Vous aide à évaluer votre stack, choisir la bonne approche et intégrer une gestion de projet adaptée à votre architecture.

npx skills add https://github.com/launchdarkly/agent-skills --skill aiconfig-projects

Configuration des projets LaunchDarkly

Vous utilisez une skill qui vous guidera à travers la configuration de la gestion des projets LaunchDarkly dans une base de code. Votre travail consiste à explorer la base de code pour comprendre la pile et les motifs, évaluer quelle approche a du sens, choisir le bon chemin d'implémentation parmi les références, exécuter la configuration et vérifier qu'elle fonctionne.

Prérequis

Choisissez l'un des deux :

  • Un token d'accès API LaunchDarkly avec la permission projects:write
  • Un serveur MCP LaunchDarkly configuré dans votre environnement

Principes fondamentaux

  1. Comprendre d'abord : Explorez la base de code pour comprendre la pile et les motifs.
  2. Choisir le bon ajustement : Sélectionnez une approche qui correspond à votre architecture.
  3. Respecter les conventions : Respectez le style et la structure du code existant.
  4. Vérifier l'intégration : Confirmez que la configuration fonctionne : l'agent effectue des vérifications et rapporte les résultats.

Détection de la clé API

Avant de demander à l'utilisateur une clé API, essayez de la détecter automatiquement :

  1. Vérifier les variables d'environnement : Cherchez LAUNCHDARKLY_API_KEY, LAUNCHDARKLY_API_TOKEN, ou LD_API_KEY
  2. Vérifier la configuration MCP : Si vous utilisez Claude, lisez ~/.claude/config.json pour mcpServers.launchdarkly.env.LAUNCHDARKLY_API_KEY
  3. Demander à l'utilisateur : Uniquement si la détection échoue, demandez à l'utilisateur sa clé API

Consultez le Guide de démarrage rapide pour les motifs d'utilisation de l'API.

Que sont les projets ?

Les projets sont les conteneurs organisationnels de haut niveau de LaunchDarkly qui contiennent :

  • Toutes vos AI Configs
  • Les feature flags et segments
  • Plusieurs environnements (Production et Test créés par défaut)

Pensez aux projets comme à des applications, services ou équipes distincts qui ont besoin de leur propre ensemble de configurations isolé.

Flux de configuration du projet

Étape 1 : Explorer la base de code

Avant d'implémenter quoi que ce soit, comprenez l'architecture existante :

  1. Identifier la pile technique :

    • Quel(s) langage(s) ? (Python, Node.js, Go, Java, etc.)
    • Quel(s) framework(s) ? (FastAPI, Express, Spring Boot, etc.)
    • Y a-t-il une intégration LaunchDarkly existante ?
  2. Vérifier la gestion de l'environnement :

    • Comment les variables d'environnement sont-elles stockées ? (fichiers .env, gestionnaire de secrets, fichiers de configuration)
    • Où la configuration est-elle chargée ? (scripts de démarrage, modules de configuration)
    • Y a-t-il des clés SDK LaunchDarkly existantes ?
  3. Chercher des motifs :

    • Y a-t-il des clients API ou modules de service existants ?
    • Comment l'intégration d'API externe est-elle généralement effectuée ?
    • Y a-t-il une CLI, un répertoire de scripts ou des outils d'administration ?
  4. Comprendre le cas d'usage :

    • S'agit-il d'un nouveau projet en cours de configuration ?
    • Ajouter à une intégration LaunchDarkly existante ?
    • Faire partie d'une architecture multi-service ?
    • Besoin de clonage de projet entre les régions/équipes ?

Étape 2 : Évaluer la situation

En fonction de votre exploration, déterminez la bonne approche :

Scénario Chemin recommandé
Nouveau projet, aucune intégration LaunchDarkly Configuration rapide - Créer un projet et enregistrer les clés SDK
Utilisation LaunchDarkly existante Ajouter à l'existant - Créer un nouveau projet ou utiliser un projet existant
Plusieurs services/microservices Multi-projet - Créer des projets par service
Multi-région ou multi-tenant Clonage de projet - Cloner un projet modèle
Configuration d'infrastructure en tant que code (IaC) Configuration automatisée - Création basée sur des scripts
Besoin d'outils de gestion de projets Outils CLI/Admin - Construire des utilitaires de gestion de projets

Étape 3 : Choisir votre chemin d'implémentation

Sélectionnez le guide de référence qui correspond à votre pile et à votre cas d'usage :

Par langage/pile :

Par cas d'usage :

Étape 4 : Implémenter l'intégration

Suivez le guide de référence choisi pour implémenter la gestion des projets. Considérations clés :

  1. Authentification API :

    • Stocker le token API de manière sécurisée
    • Suivre les motifs existants de gestion des secrets
    • Ne jamais valider les tokens dans le contrôle de version
  2. Nommage du projet :

    • Utiliser des noms cohérents et descriptifs
    • Suivre les conventions de nommage existantes
    • Clés de projet : minuscules, tirets, commencer par une lettre
  3. Gestion des clés SDK :

    • Extraire et stocker les clés SDK pour chaque environnement
    • Utiliser le même motif que les autres secrets dans votre base de code
    • Envisager des clés séparées pour les environnements test/staging/production
  4. Gestion des erreurs :

    • Gérer les projets existants gracieusement (conflit 409)
    • Fournir des messages d'erreur clairs
    • Ne pas échouer silencieusement

Étape 5 : Vérifier la configuration

Après la création du projet, vérifiez qu'il fonctionne :

  1. Récupérer pour confirmer son existence. Préférez l'outil MCP get-project au curl brut — il retourne un objet typé que vous pouvez inspecter directement. Si vous devez appeler l'API REST :

    curl -X GET "https://app.launchdarkly.com/api/v2/projects/{projectKey}?expand=environments" \
      -H "Authorization: {api_token}"

    Ne dirigez pas la réponse directement dans un filtre de style .environments.items[] avec jq. La forme de environments varie selon le paramètre expand — parfois c'est {items: [...]}, parfois un tableau brut — et un filtre improvisé échouera avec Cannot index array with string "items". Exécutez jq -e . d'abord pour inspecter la forme réelle, ou utilisez jq '.environments | if type == "object" then .items else . end' pour gérer les deux cas.

  2. Tester l'intégration du SDK : Exécutez une vérification rapide pour vous assurer que la clé SDK fonctionne :

    import ldclient
    from ldclient.config import Config
    
    ldclient.set_config(Config("{sdk_key}"))
    # Le SDK s'initialise avec succès
    
    # Toujours vider les événements avant de fermer — les événements en attente risquent d'être
    # perdus sinon, dans les scripts de courte durée et les services de longue durée.
    ldclient.get().flush()
    ldclient.get().close()
  3. Rapporter les résultats :

    • ✓ Le projet existe et possède des environnements
    • ✓ Les clés SDK sont présentes et valides
    • ✓ Le SDK peut s'initialiser (ou signaler tout problème)

Meilleures pratiques pour les clés de projet

Les clés de projet doivent suivre ces règles :

✓ Bons exemples :
  - "support-ai"
  - "chat-bot-v2"
  - "internal-tools"

✗ Mauvais exemples :
  - "Support_AI"     # Pas de majuscules ni de tirets bas
  - "123-project"    # Doit commencer par une lettre  
  - "my.project"     # Pas de points autorisés

Recommandations de nommage :

  • Garder les clés courtes mais descriptives
  • Utiliser l'équipe/service/objectif comme schéma de nommage
  • Être cohérent dans votre organisation

Motifs d'organisation courants

Par équipe

platform-ai       → AI de l'équipe Platform
customer-ai       → AI de l'équipe Customer Success
internal-ai       → AI des outils internes

Par application/service

mobile-ai         → AI de l'application mobile
web-ai            → AI de l'application web
api-ai            → AI du service API

Par région/déploiement

ai-us             → Région US
ai-eu             → Région Europe
ai-apac           → Région Asie-Pacifique

Cas limites

Situation Action
Le projet existe déjà Vérifier que c'est le bon ; l'utiliser ou créer avec une clé différente
Besoin de plusieurs projets Créer séparément pour chaque service/région/équipe
Configurations partagées entre services Utiliser le même projet, séparer par contexte SDK
Token manque de permissions Demander projects:write ou utiliser le serveur MCP
Conflit de nom de projet Les clés doivent être uniques, les noms peuvent être similaires

Ce qu'il NE FAUT PAS faire

  • Ne créez pas de projets sans d'abord comprendre le cas d'usage
  • Ne validez pas les tokens API ou les clés SDK dans le contrôle de version
  • N'utilisez pas les clés SDK de production dans les environnements test/développement
  • Ne créez pas de projets en double inutilement
  • Ne sautez pas la phase d'exploration

Étapes suivantes

Après la configuration des projets :

  1. Créer des AI Configs - Utilisez la skill aiconfig-create
  2. Configurer l'intégration du SDK - Utilisez la skill aiconfig-sdk
  3. Configurer le ciblage - Utilisez la skill aiconfig-targeting

Skills connexes

  • aiconfig-create - Créer des AI Configs dans les projets
  • aiconfig-sdk - Intégrer le SDK dans votre application
  • aiconfig-targeting - Configurer le ciblage d'AI Config
  • aiconfig-variations - Gérer les variations de configuration

Références

Skills similaires