Skip to main content

Updates für mehrere Ökosysteme

Multiökosystemupdates kombinieren Abhängigkeitsupdates über mehrere Paketökosysteme hinweg in einer einzigen Pull-Anforderung, wodurch der Aufwand für die Überprüfung reduziert und der Updateworkflow vereinfacht wird.

Was sind Multi-Ökosystem-Updates?

Multi-Ökosystem-Updates ermöglichen Dependabot die Gruppierung von Abhängigkeitsupdates für verschiedene Paketökosysteme, wie npm, Docker, Python und Terraform, in einer einzigen Pullanforderung pro Gruppe.

Anstatt separate Pullanforderungen für jedes Ökosystem zu erhalten, erhalten Sie eine konsolidierte Pull-Anforderung, die alle Updates für die Ökosysteme in dieser Gruppe enthält.

Die Funktionsweise von Updates für mehrere Ökosysteme

Wenn Sie eine Multiökosystemgruppe konfigurieren:

  1. Sie definieren die Gruppe mit einem Zeitplan im multi-ecosystem-groups Abschnitt Ihrer dependabot.yml Datei.
  2. Sie weisen der Gruppe mithilfe des multi-ecosystem-group Schlüssels einzelne Paketökosysteme zu.
  3. Sie geben an, welche Abhängigkeiten einbezogen werden sollen, indem Sie den patterns Schlüssel für jedes Ökosystem verwenden.
  4. Dependabot sucht entsprechend dem Zeitplan der Gruppe nach Aktualisierungen.
  5. Eine einzelne Pull-Anforderung wird erstellt, die Updates aller Ökosysteme in der Gruppe enthält.
  6. Die PR verwendet die Gruppen-ID sowohl im Branch-Namen als auch im Titel.

Wann man Updates für mehrere Ökosysteme verwenden sollte

Updates für mehrere Ökosysteme sind besonders nützlich für:

  •         **Infrastrukturprojekte** , die mehrere Technologien verwenden (Docker, Terraform, Python-Skripts)
    
  •         **Full-Stack-Anwendungen** mit Frontend- und Back-End-Abhängigkeiten, die zusammen aktualisiert werden sollen
    
  •         **Plattformübergreifende Bibliotheken** , die synchronisierte Protokollversionen in verschiedenen Sprachen benötigen
    
  •         **Monorepos** mit Diensten in verschiedenen Sprachen, die sich eine gemeinsame Versionierung teilen
    

Multiökosystem im Vergleich zu Einzelökosystemgruppen

Dependabot unterstützt zwei Arten von Gruppierung:

          **Multiökosystemgruppen:**
  • Schließen Sie mehrere package-ecosystem-Einträge in der dependabot.yml-Datei ein.

  • Verwenden Sie den patterns Schlüssel, um festzulegen, welche Abhängigkeiten einzuschließen sind

  • Für sie ist ein eigener Zeitplan im Abschnitt multi-ecosystem-groups definiert.

  • Verwenden des multi-ecosystem-group Schlüssels zum Zuweisen von Ökosystemen zu einer Gruppe

            **Einzelökosystemgruppen:**
    
  • Arbeiten innerhalb eines Paketökosystems

  • Verwenden des groups Schlüssels innerhalb eines Eintrags updates

  • Erbe den Zeitplan vom übergeordneten updates-Eintrag

  • Besser zum Organisieren von Abhängigkeiten innerhalb eines einzelnen Paket-Managers

Verwenden Sie Multi-Ökosystem-Gruppen, wenn Sie Updates über verschiedene Paketmanager hinweg kombinieren möchten. Verwenden Sie Einzelökosystemegruppen, wenn Sie Abhängigkeiten innerhalb eines einzelnen Paket-Managers organisieren möchten (z. B. gruppieren sie alle AWS-bezogenen npm-Pakete zusammen).

Verhalten beim Zusammenführen von Konfigurationen

Einige Konfigurationsoptionen können sowohl auf Gruppenebene als auch auf Ökosystemebene festgelegt werden. Dependabot kombiniert diese Werte unterschiedlich, abhängig von der Option:

          **Additive Optionen** (Werte werden zusammengeführt):
  •           `assignees` – Alle zugewiesenen Elemente aus beiden Ebenen werden der Pullanforderung zugewiesen.
    
  •         `labels` - Alle Bezeichnungen aus beiden Ebenen werden auf die Pullanforderung angewendet.
    

Wenn Sie beispielsweise @platform-team auf Gruppenebene und @docker-admin auf Docker-Ökosystemebene zuweisen, wird die resultierende Pull-Anforderung sowohl @platform-team als auch @docker-admin zugewiesen.

Optionen für "Nur Gruppieren" (können nur auf Gruppenebene festgelegt werden):

  • milestone
  • commit-message
  • target-branch
  • pull-request-branch-name

Wenn Sie versuchen, diese Optionen auf Ökosystemebene festzulegen, tritt ein Konfigurationsfehler auf.

Eine vollständige Referenz zu allen verfügbaren Konfigurationsoptionen und deren Verhalten finden Sie unter Referenz zu Dependabot-Optionen.

Anwendungsfälle

Infrastrukturprojekte

Infrastrukturcode verwendet häufig mehrere Technologien– Docker-Container, Terraform für Cloudressourcen und Python-Skripts zur Automatisierung. Das Gruppieren dieser Updates vereinfacht die Überprüfung und Bereitstellungskoordination.

          **Warum gruppieren Sie diese:** Infrastrukturänderungen müssen häufig gemeinsam bereitgestellt werden. Durch die Verwendung separater PRs für jede Technologie entsteht ein Koordinationsaufwand und macht es schwieriger, nachzuverfolgen, was als Einheit bereitgestellt werden muss.

          **Beispielszenario:** Sie verfügen über Docker-Images für Ihre Dienste, Terraform-Module für AWS-Ressourcen und Python-Skripts für Automatisierungsaufgaben. Eine einzelne wöchentliche "Infrastruktur"-Pullanforderung enthält Updates für alle drei, wodurch es einfacher ist, Infrastrukturänderungen zusammen zu überprüfen und bereitzustellen.

Vollständige Anwendungen

Webanwendungen mit Frontend- und Back-End-Komponenten profitieren von der gemeinsamen Aktualisierung von Abhängigkeiten, um Kompatibilität zu gewährleisten und Tests zu optimieren.

          **Warum gruppieren Sie diese:** Frontend und Back-End hängen häufig voneinander ab. Durch die gemeinsame Aktualisierung wird sichergestellt, dass Sie den vollständigen Anwendungsstapel in einem Einzigen testen können, anstatt Frontend-Änderungen zusammenzuführen und später Back-End-Inkompatibilitäten zu ermitteln.

          **Beispielszenario:** Ihr React-Frontend- und Rails-Back-End werden täglich in einer einzigen Pullanforderung "App-Abhängigkeiten" aktualisiert, sodass Sie die vollständige Anwendung vor dem Zusammenführen testen können.

Plattformübergreifende Bibliotheken

Bibliotheken oder Dienste, die dieselben Protokolle in verschiedenen Sprachen (z. B. gRPC und Protokollpuffer) verwenden, müssen Bibliotheksversionen über alle Implementierungen hinweg synchronisiert lassen.

          **Warum gruppieren Sie diese:** Protokollbibliotheken müssen über verschiedene Sprachimplementierungen hinweg kompatibel bleiben. Durch das Gemeinsame Aktualisieren werden Versionskonflikte verhindert, die zu Kommunikationsfehlern zwischen Diensten führen könnten.

          **Beispielszenario:** Ihre Node.js- und Ruby-Dienste verwenden sowohl gRPC. Ein einzelner Pull-Request aktualisiert sowohl `@grpc/grpc-js` (npm) als auch `grpc` (Bundler) gleichzeitig, um die Protokollkompatibilität sicherzustellen.

Monorepos mit mehreren Diensten

Große Repositorys, die mehrere Dienste in unterschiedlichen Sprachen enthalten, profitieren von der Gruppierung von Updates nach Teamverantwortung oder Bereitstellungsrhythmen.

          **Gründe für die Gruppierung:** Verschiedene Teams besitzen verschiedene Teile des Monorepos, und Aktualisierungen sollten an die entsprechenden Überprüfer weitergeleitet werden. Oder Dienste werden zusammen bereitgestellt und benötigen koordinierte Updates.

          **Beispielszenario:** Ihr Monorepo verfügt über einen Python-API-Dienst, einen Go-Worker-Dienst und ein Node.js Frontend. Sie erstellen separate Gruppen für "Back-End-Services" (Python + Go) und "frontend" (Node.js), die jeweils mit unterschiedlichen Zeitplänen und Zuweisungen.

Beispiel: Komplexe Konfiguration mit mehreren Gruppen

In diesem Beispiel wird gezeigt, wie ein komplexes Projekt mehrere Gruppen mit unterschiedlichen Updatestrategien verwenden kann:

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"

Nächste Schritte

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