Mises à jour multi-écosystèmes

Les mises à jour multi-écosystèmes combinent les mises à jour des dépendances dans plusieurs écosystèmes de packages en une seule pull request, réduisant la surcharge lors de la révision et simplifiant votre flux de mise à jour.

Dans cet article

Qu’est-ce que les mises à jour multi-écosystèmes ?

Les mises à jour multi-écosystèmes permettent à Dependabot de regrouper les mises à jour des dépendances entre différents écosystèmes de paquets tels que npm, Docker, Python et Terraform dans une seule requête d'extraction par groupe.

Au lieu de recevoir des demandes de tirage distinctes pour chaque écosystème, vous recevez une demande de tirage consolidée contenant toutes les mises à jour des écosystèmes de ce groupe.

Fonctionnement des mises à jour d'écosystèmes multiples

Lorsque vous configurez un groupe multi-écosystème :

  1. Vous définissez le groupe avec une planification dans la multi-ecosystem-groups section de votre dependabot.yml fichier.
  2. Vous affectez des écosystèmes de package individuels au groupe à l’aide de la multi-ecosystem-group clé.
  3. Vous spécifiez les dépendances à inclure à l’aide de la patterns clé pour chaque écosystème.
  4. Dependabot vérifie les mises à jour selon le calendrier du groupe.
  5. Une pull request unique est créée contenant les mises à jour de tous les écosystèmes du groupe.
  6. La pull request utilise l’identificateur de groupe dans le nom et le titre de la branche.

Quand utiliser des mises à jour multi-écosystème

Les mises à jour multi-écosystèmes sont particulièrement utiles pour :

  •         **Projets d’infrastructure** qui utilisent plusieurs technologies (Docker, Terraform, scripts Python)

  •         **Applications de pile complète** avec des dépendances front-end et back-end qui doivent être mises à jour ensemble

  •         **Bibliothèques multiplateformes** nécessitant des versions de protocole synchronisées entre les langages

  •         **Monorepos** avec des services dans différents langages qui partagent le contrôle de version

Multi-écosystème et groupes à écosystème unique

Dependabot prend en charge deux types de regroupement :

          **Groupes multi-écosystèmes :**

  • Étendre plusieurs package-ecosystem entrées dans votre dependabot.yml fichier

  • Exiger la patterns clé pour spécifier les dépendances à inclure

  • Avoir leur propre planification définie dans la multi-ecosystem-groups section

  • Utiliser la multi-ecosystem-group clé pour affecter des écosystèmes à un groupe

            **Groupes à écosystème unique :**

  • Travailler au sein d’un écosystème de packages

  • Utiliser la groups clé dans une updates entrée

  • Hériter de la planification depuis l'entrée parente updates

  • Mieux pour organiser les dépendances au sein d’un seul gestionnaire de package

Utilisez des groupes multi-écosystèmes lorsque vous souhaitez combiner des mises à jour entre différents gestionnaires de packages. Utilisez des groupes à écosystème unique lorsque vous souhaitez organiser les dépendances au sein d’un seul gestionnaire de packages (par exemple, regrouper tous les packages npm liés à AWS).

Comportement de fusion de configuration

Certaines options de configuration peuvent être définies au niveau du groupe et au niveau de l’écosystème. Dependabot combine ces valeurs différemment en fonction de l’option :

          **Options additives** (valeurs fusionnées) :

* assignees - Tous les assignés des deux niveaux sont affectés à la pull request * labels - Toutes les étiquettes des deux niveaux sont appliquées à la demande de tirage

Par exemple, si vous affectez @platform-team au niveau du groupe et @docker-admin au niveau de l’écosystème Docker, la demande de tirage résultante sera affectée à la fois @platform-team et @docker-admin.

          **Options de groupe uniquement** (ne peuvent être définies qu’au niveau du groupe) :
  • milestone
  • commit-message
  • target-branch
  • pull-request-branch-name

La tentative de définition de ces options au niveau de l’écosystème entraîne une erreur de configuration.

Pour obtenir une référence complète de toutes les options de configuration disponibles et de leur comportement, consultez Référence des options Dependabot.

Cas d’utilisation

Projets d’infrastructure

Le code d’infrastructure utilise souvent plusieurs technologies : conteneurs Docker, Terraform pour les ressources cloud et scripts Python pour l’automatisation. Le regroupement de ces mises à jour simplifie la révision et la coordination du déploiement.

          **Pourquoi regrouper ces éléments :** Les modifications d’infrastructure doivent souvent être déployées ensemble. Le fait d’avoir des demandes de fusion distinctes pour chaque technologie crée une surcharge de coordination et rend plus difficile le suivi de ce qui doit être déployé comme une seule unité.

          **Exemple de scénario :** Vous disposez d’images Docker pour vos services, modules Terraform pour les ressources AWS et scripts Python pour les tâches d’automatisation. Une seule pull request « infrastructure » hebdomadaire contient des mises à jour pour les trois, ce qui facilite la révision et le déploiement des modifications d’infrastructure.

Applications à pile complète

Les applications web avec des composants front-end et back-end tirent parti de la mise à jour des dépendances ensemble pour garantir la compatibilité et simplifier les tests.

          **Pourquoi regrouper ces éléments :** Le serveur frontal et le back-end dépendent souvent les uns des autres. La mise à jour ensemble vous permet de tester la pile d’applications complète en une seule fois, plutôt que de fusionner les modifications frontales, puis de découvrir les incompatibilités de back-end ultérieurement.

          **Exemple de scénario :** Votre frontend React et backend Rails sont mis à jour quotidiennement dans une seule pull request « app-dependencies », ce qui vous permet de tester l'application complète ensemble avant l'intégration.

Bibliothèques multiplateformes

Les bibliothèques ou services qui utilisent les mêmes protocoles dans différents langages (comme les mémoires tampons de protocole et gRPC) doivent maintenir la synchronisation des versions de bibliothèque dans toutes les implémentations.

          **Pourquoi regrouper ces éléments :** Les bibliothèques de protocole doivent rester compatibles entre différentes implémentations de langage. Les mettre à jour ensemble empêchent les incompatibilités de version susceptibles d’entraîner des échecs de communication entre les services.

          **Exemple de scénario :** Vos services Node.js et Ruby utilisent tous deux gRPC. Une pull request unique met à jour à la fois `@grpc/grpc-js` (npm) et `grpc` (bundler), garantissant ainsi la compatibilité du protocole.

Monorepos avec plusieurs services

Les dépôts volumineux contenant plusieurs services dans différentes langues bénéficient du regroupement des mises à jour par responsabilité d’équipe ou par cadence de déploiement.

          **Pourquoi regrouper ces éléments :** Différentes équipes possèdent différentes parties du monorepo, et les mises à jour doivent être acheminées vers les réviseurs appropriés. Ou les services sont déployés ensemble et nécessitent des mises à jour coordonnées.

          **Exemple de scénario :** Votre monorepo dispose d’un service d’API Python, d’un service De travail Go et d’un serveur frontal Node.js. Vous créez des groupes distincts pour « backend-services » (Python + Go) et « frontend » (Node.js), chacun avec des planifications et des affectations différentes.

Exemple : Configuration multi-groupe complexe

Cet exemple montre comment un projet complexe peut utiliser plusieurs groupes avec différentes stratégies de mise à jour :

YAML
version: 2

multi-ecosystem-groups:
  # Infrastructure updates - weekly, tracked in milestone
  infrastructure:
    schedule:
      interval: "weekly"
    assignees: ["@platform-team"]
    labels: ["infrastructure", "dependencies"]
    milestone: 10

  # Application code updates - daily, with development team
  full-stack:
    schedule:
      interval: "daily"
    assignees: ["@full-stack-team"]
    labels: ["full-stack"]

updates:
  # Docker images - infrastructure group with additional docker expertise
  - package-ecosystem: "docker"
    directory: "/"
    patterns: ["nginx", "redis", "postgres"]
    assignees: ["@docker-admin"]      # Adds to @platform-team
    labels: ["docker"]                 # Adds to infrastructure, dependencies
    multi-ecosystem-group: "infrastructure"

  # Terraform - infrastructure group
  - package-ecosystem: "terraform"
    directory: "/"
    patterns: ["aws", "terraform-*"]
    multi-ecosystem-group: "infrastructure"

  # Frontend - full-stack group with frontend focus
  - package-ecosystem: "npm"
    directory: "/frontend"
    patterns: ["react", "lodash", "@types/*"]
    labels: ["frontend"]               # Adds to full-stack
    multi-ecosystem-group: "full-stack"

  # Backend - full-stack group with backend specialist
  - package-ecosystem: "bundler"
    directory: "/backend"
    patterns: ["rails", "pg", "sidekiq"]
    assignees: ["@backend-dev"]        # Adds to @full-stack-team
    multi-ecosystem-group: "full-stack"

Étapes suivantes

  •         [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-multi-ecosystem-updates)