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:
- Sie definieren die Gruppe mit einem Zeitplan im
multi-ecosystem-groupsAbschnitt Ihrerdependabot.ymlDatei. - Sie weisen der Gruppe mithilfe des
multi-ecosystem-groupSchlüssels einzelne Paketökosysteme zu. - Sie geben an, welche Abhängigkeiten einbezogen werden sollen, indem Sie den
patternsSchlüssel für jedes Ökosystem verwenden. - Dependabot sucht entsprechend dem Zeitplan der Gruppe nach Aktualisierungen.
- Eine einzelne Pull-Anforderung wird erstellt, die Updates aller Ökosysteme in der Gruppe enthält.
- 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 derdependabot.yml-Datei ein. -
Verwenden Sie den
patternsSchlüssel, um festzulegen, welche Abhängigkeiten einzuschließen sind -
Für sie ist ein eigener Zeitplan im Abschnitt
multi-ecosystem-groupsdefiniert. -
Verwenden des
multi-ecosystem-groupSchlüssels zum Zuweisen von Ökosystemen zu einer Gruppe**Einzelökosystemgruppen:** -
Arbeiten innerhalb eines Paketökosystems
-
Verwenden des
groupsSchlüssels innerhalb eines Eintragsupdates -
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):
milestonecommit-messagetarget-branchpull-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:
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"
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)