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 projects

Configuration des Projets LaunchDarkly

Vous utilisez une skill qui vous guidera dans la configuration de la gestion des projets LaunchDarkly dans une codebase. Votre rôle est d'explorer le codebase pour comprendre la stack et les patterns, d'évaluer l'approche qui convient, de choisir le bon chemin d'implémentation parmi les références, d'exécuter la configuration et de vérifier qu'elle fonctionne.

Prérequis

Choisir l'un des éléments suivants :

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

Principes Fondamentaux

  1. Comprendre d'abord : Explorez le codebase pour comprendre la stack et les patterns.
  2. Choisir la bonne approche : 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érifiez les variables d'environnement : Recherchez LAUNCHDARKLY_API_KEY, LAUNCHDARKLY_API_TOKEN, ou LD_API_KEY
  2. Vérifiez la configuration MCP : Si vous utilisez Claude, lisez ~/.claude/config.json pour mcpServers.launchdarkly.env.LAUNCHDARKLY_API_KEY
  3. Demandez à l'utilisateur : Seulement si la détection échoue, demandez à l'utilisateur sa clé API

Voir Quick Start pour les patterns d'utilisation de l'API.

Que sont les Projets ?

Les projets sont les conteneurs organisationnels de niveau supérieur de LaunchDarkly qui contiennent :

  • Toutes vos configurations
  • 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 isolé de configurations.

Workflow de Configuration des Projets

Étape 1 : Explorer le Codebase

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

  1. Identifiez la tech stack :

    • 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érifiez 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. Recherchez les patterns :

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

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

Étape 2 : Évaluer la Situation

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

Scénario Chemin Recommandé
Nouveau projet, pas d'intégration LaunchDarkly Configuration Rapide - Créer un projet et sauvegarder les clés SDK
Utilisation existante de LaunchDarkly Ajouter à l'Existant - Créer un nouveau projet ou utiliser un existant
Plusieurs services/microservices Multi-Projet - Créer des projets par service
Multi-région ou multi-tenant Clonage de Projets - Cloner un projet template
Configuration Infrastructure-as-Code (IaC) Configuration Automatisée - Création basée sur des scripts
Besoin d'outils de gestion de projets CLI/Outils d'Administration - 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 stack et votre cas d'usage :

Par Langage/Stack :

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 :

    • Stockez le jeton API de manière sécurisée
    • Suivez les patterns de gestion des secrets existants
    • Ne commitez jamais les jetons dans le contrôle de version
  2. Nommage des Projets :

    • Utilisez des noms cohérents et descriptifs
    • Respectez les conventions de nommage existantes
    • Clés de projet : minuscules, tirets, commencent par une lettre
  3. Gestion des Clés SDK :

    • Extrayez et stockez les clés SDK pour chaque environnement
    • Utilisez le même pattern que les autres secrets de votre codebase
    • Envisagez des clés séparées pour test/staging/production
  4. Gestion des Erreurs :

    • Gérez les projets existants gracieusement (conflit 409)
    • Fournissez des messages d'erreur clairs
    • Ne échouez pas silencieusement

Étape 5 : Vérifier la Configuration

Après avoir créé le projet, vérifiez qu'il fonctionne :

  1. Récupérez-le pour confirmer son existence. Préférez l'outil MCP get-project à un 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 pipez 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 fait à la main échouera avec Cannot index array with string "items". Exécutez d'abord jq -e . pour inspecter la forme réelle, ou utilisez jq '.environments | if type == "object" then .items else . end' pour gérer les deux cas.

  2. Testez l'intégration 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}"))
    # SDK initializes successfully
    
    # Always flush events before closing — trailing events are at risk of being
    # lost otherwise, in short-lived scripts and long-running services alike.
    ldclient.get().flush()
    ldclient.get().close()
  3. Rapportez les résultats :

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

Bonnes Pratiques des Clés de Projet

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

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

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

Recommandations de Nommage :

  • Gardez les clés courtes mais descriptives
  • Utilisez l'équipe/service/objectif comme schéma de nommage
  • Soyez cohérent dans votre organisation

Patterns d'Organisation Courants

Par Équipe

platform-ai       → Agent de l'Équipe Platform
customer-ai       → Agent de l'Équipe Customer Success
internal-ai       → Agent de l'Équipe Internal Tools

Par Application/Service

mobile-ai         → Configs de l'App Mobile
web-ai            → Configs de l'App Web
api-ai            → Configs 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érifiez que c'est le bon ; utilisez-le ou créez-en un avec une clé différente
Besoin de plusieurs projets Créez-les séparément pour chaque service/région/équipe
Configs partagées entre services Utilisez le même projet, séparez par contexte SDK
Le jeton n'a pas les permissions Demandez la permission projects:write ou utilisez 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 comprendre le cas d'usage d'abord
  • Ne committez pas les jetons API ou clés SDK dans le contrôle de version
  • N'utilisez pas les clés SDK de production dans les environnements de test/développement
  • Ne créez pas de projets dupliqués inutilement
  • Ne sautez pas la phase d'exploration

Prochaines Étapes

Après la configuration des projets :

  1. Créer des configurations - Utilisez la skill configs-create
  2. Configurer l'Intégration SDK - Utilisez la skill sdk
  3. Configurer le Ciblage - Utilisez la skill configs-targeting

Skills Connexes

  • configs-create - Créer des configurations dans les projets
  • sdk - Intégrer le SDK dans votre application
  • configs-targeting - Configurer le ciblage des configurations
  • configs-variations - Gérer les variations de configurations

Références

Skills similaires