{"meta":{"title":"Optimieren der Erstellung von Pull Requests für Versionsupdates von Dependabot","intro":"Erfahren Sie, wie Sie Ihre Dependabot Pull-Anforderungen optimieren und effizient verwalten können.","product":"Sicherheit und Codequalität","breadcrumbs":[{"href":"/de/code-security","title":"Sicherheit und Codequalität"},{"href":"/de/code-security/tutorials","title":"Anleitungen"},{"href":"/de/code-security/tutorials/secure-your-dependencies","title":"Sichern Sie Ihre Abhängigkeiten"},{"href":"/de/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates","title":"Optimieren der PR-Erstellung"}],"documentType":"article"},"body":"# Optimieren der Erstellung von Pull Requests für Versionsupdates von Dependabot\n\nErfahren Sie, wie Sie Ihre Dependabot Pull-Anforderungen optimieren und effizient verwalten können.\n\nStandardmäßig öffnet Dependabot eine neue Pull Request, um jede Abhängigkeit zu aktualisieren. Wenn du Sicherheitsupdates aktivierst, werden neue Pull Requests geöffnet, wenn eine anfällige Abhängigkeit gefunden wird. Wenn du Versionsupdates für ein oder mehrere Ökosysteme konfigurierst, werden neue Pull Requests geöffnet, wenn neue Versionen von Abhängigkeiten verfügbar sind, wobei die in der Datei `dependabot.yml` definierte Häufigkeit verwendet wird.\n\nWenn Ihr Projekt viele Abhängigkeiten aufweist, stellen Sie möglicherweise fest, dass Sie eine sehr große Anzahl von Dependabot Pullanforderungen zum Überprüfen und Zusammenführen haben, was schnell schwierig zu verwalten ist.\n\nEs gibt eine Reihe von Anpassungsoptionen, die Sie implementieren können, um Aktualisierungs-Pullanforderungen so zu optimieren Dependabot , dass sie an Ihre Prozesse angepasst werden, z. B.:\n\n* ```\n            **Steuerung der Häufigkeit**, mit der Dependabot nach neueren Versionen Ihrer Abhängigkeiten mit `schedule` sucht.\n  ```\n* **Priorisieren wichtiger Updates** mit `groups`\n\n## Steuern der Häufigkeit und Zeiten von Abhängigkeitsupdates\n\n```\n          Dependabot führt die Überprüfung auf Versionsupdates in der von Ihnen in der Konfigurationsdatei festgelegten Häufigkeit aus, wobei das erforderliche Feld auf `schedule.interval`, `daily`, `weekly`, `monthly`, `quarterly`, `semiannually`, `yearly` oder `cron` gesetzt werden muss (siehe [`cronjob`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cronjob)).\n```\n\nStandardmäßig wird die Arbeitslast durch Dependabot ausgeglichen, indem eine zufällige Zeit zum Prüfen und Erstellen von Pull-Anfragen für Abhängigkeitsaktualisierungen zugewiesen wird.\n\nUm jedoch Ablenkung zu reduzieren oder Zeit und Ressourcen für die Überprüfung und Durchführung von Versionsupdates besser zu organisieren, kann es hilfreich sein, die Häufigkeit und die Zeiten zu ändern. Beispielsweise möchten Sie vielleicht, dass Dependabot lieber wöchentliche statt tägliche Überprüfungen auf Aktualisierungen durchführt, und zwar zu einem Zeitpunkt, der sicherstellt, dass Pull-Anfragen rechtzeitig vor der Triage-Sitzung Ihres Teams gestellt werden.\n\n### Ändern der Häufigkeit und Zeiten für Abhängigkeitsupdates\n\nSie können `schedule` in Verbindung mit mehreren Optionen nutzen, um die Häufigkeit und den Zeitpunkt der Dependabot-Überprüfung auf Versionsupdates zu ändern.\n\nDie folgende Beispieldatei `dependabot.yml` ändert die npm-Konfiguration, um festzulegen, dass Dependabot jeden Dienstag um 02:00 Uhr japanischer Standardzeit (UTC +09:00) nach Versionsaktualisierungen für npm-Abhängigkeiten suchen soll.\n\n```yaml copy\n# `dependabot.yml` file with\n# customized schedule for version updates\n\nversion: 2\nupdates:\n  # Keep npm dependencies up to date\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    # Check the npm registry every week on Tuesday at 02:00 Japan Standard Time (UTC +09:00)\n    schedule:\n      interval: \"weekly\"\n      day: \"tuesday\"\n      time: \"02:00\"\n      timezone: \"Asia/Tokyo\"\n```\n\nWeitere Informationen findest du unter [Zeitplan](/de/code-security/dependabot/working-with-dependabot/dependabot-options-reference#schedule-).\n\n### Einrichten eines Abkühlzeitraums für Abhängigkeitsupdates\n\nSie können mit einer Kombination von Optionen verwenden  `cooldown` , um zu steuern, wann Dependabot Pullanforderungen für **Versionsupdates** erstellt werden, aber keine **Sicherheitsupdates**.\n\nDie folgende `dependabot.yml`-Beispieldatei zeigt einen Abkühlzeitraum, der auf die Abhängigkeiten `requests`, `numpy` und die Abhängigkeiten mit dem Präfix `pandas` oder `django` angewendet wird, jedoch nicht auf die Abhängigkeit namens `pandas` (genaue Übereinstimmung), die über die Liste **exclude** ausgeschlossen wird.\n\n```yaml copy\nversion: 2\nupdates:\n  - package-ecosystem: \"pip\"\n    directory: \"/\"\n    schedule:\n      interval: \"daily\"\n    cooldown:\n      default-days: 5\n      semver-major-days: 30\n      semver-minor-days: 7\n      semver-patch-days: 3\n      include:\n        - \"requests\"\n        - \"numpy\"\n        - \"pandas*\"\n        - \"django\"\n      exclude:\n        - \"pandas\"\n```\n\n* Die Anzahl der Abkühltage muss zwischen 1 und 90 liegen.\n* Die maximal zulässige Anzahl von Elementen in den Listen `include` und `exclude`, die mit `cooldown` verwendet werden können, beträgt jeweils 150.\n\n> \\[!NOTE]\n> Um **alle Abhängigkeiten** für einen Abkühlzeitraum zu berücksichtigen, hast du folgende Möglichkeiten:\n>\n> * Lasse die Option `include` aus, die die Abkühlung auf alle Abhängigkeiten anwendet.\n> * Verwende `\"*\"` in `include`, um die Abkühleinstellungen auf alles anzuwenden.\n>   Es wird empfohlen, `exclude` zu verwenden, um **nur\\*\\*\\*\\*bestimmte Abhängigkeiten** aus den Abkühleinstellungen auzuschließen.\n\nSemVer wird für die meisten Paket-Manager unterstützt. Updates für neue Versionen für Abhängigkeiten im Abkühlzeitraum werden wie folgt zurückgestellt:\n\n* Wichtige Updates: Verzögert um 30 Tage (`semver-major-days: 30`).\n* Kleine Updates: Verzögert um 7 Tage (`semver-minor-days: 7`).\n* Patch-Updates: um 3 Tage verzögert (`semver-patch-days: 3`).\n\nSiehe auch [`cooldown`](/de/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cooldown-).\n\n## Priorisieren wichtiger Updates\n\n### Gruppieren verwandter Abhängigkeiten\n\nDu kannst `groups` verwenden, um Updates für mehrere Abhängigkeiten in einem einzelnen Pull Request zu konsolidieren. Auf diese Weise kannst du dich auf riskantere Updates konzentrieren und die Zeit für die Überprüfung von Nebenversionsupdates minimieren. Du kannst beispielsweise Updates für Nebenversions- oder Patchupdates für Entwicklungsabhängigkeiten in einem einzigen Pull Request kombinieren und eine dedizierte Gruppe für Sicherheits- oder Versionsupdates erstellen, die sich auf einen wichtigen Bereich deiner Codebasis auswirken.\n\nDu musst Gruppen pro einzelnem Paketökosystem konfigurieren, damit du mehrere Gruppen pro Paketökosystem mithilfe einer Kombination von Kriterien erstellen kannst:\n\n* Dependabot Updatetyp: `applies-to`\n* Abhängigkeitstyp: `dependency-type`\n* Abhängigkeitsname: `patterns` und `exclude-patterns`\n* Grade der semantischen Versionierung: `update-types`\n\nInformationen zum Anzeigen aller unterstützten Werte für jedes Kriterium findest du unter [`groups`](/de/code-security/dependabot/working-with-dependabot/dependabot-options-reference#groups--).\n\nIn den folgenden Beispielen werden verschiedene Methoden zum Erstellen von Gruppen von Abhängigkeiten mithilfe der Kriterien gezeigt.\n\n### Beispiel 1: Drei Versionsupdategruppen\n\nIn diesem Beispiel hat die Datei `dependabot.yml` folgende Funktion:\n\n* Erstellt drei Gruppen namens `production-dependencies`, `development-dependencies` und `rubocop`\n* Verwendet `patterns` und `dependency-type`, um Abhängigkeiten in die Gruppe einzuschließen\n* Verwendet `exclude-patterns`, um eine Abhängigkeit (oder mehrere) aus der Gruppe auszuschließen\n\n```yaml\nversion: 2\nupdates:\n  # Keep bundler dependencies up to date\n  - package-ecosystem: \"bundler\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      production-dependencies:\n        dependency-type: \"production\"\n      development-dependencies:\n        dependency-type: \"development\"\n        exclude-patterns:\n          - \"rubocop*\"\n      rubocop:\n        patterns:\n          - \"rubocop*\"\n```\n\nInfolgedessen:\n\n* Versionsupdates werden nach Abhängigkeitstyp gruppiert.\n* Entwicklungsabhängigkeiten, die dem Muster `rubocop*` entsprechen, werden aus der `development-dependencies`-Gruppe ausgeschlossen.\n* Stattdessen werden Entwicklungsabhängigkeiten, die mit `rubocop*` übereinstimmen, in die `rubocop`-Gruppe aufgenommen. Aufgrund der Sortierung werden Produktionsabhängigkeiten, die `rubocop*` entsprechen, in die `production-dependencies`-Gruppe einbezogen.\n* Darüber hinaus werden alle Gruppen standardmäßig nur auf Versionsupdates angewendet, da der `applies-to`-Schlüssel nicht vorhanden ist.\n\n### Beispiel 2: Gruppierte Updates mit ausgeschlossenen Abhängigkeiten\n\nIn diesem Beispiel hat die Datei `dependabot.yml` folgende Funktion:\n\n* Erstellt eine Gruppe namens „`support-dependencies`“ als Teil einer angepassten Bundler-Konfiguration\n* Verwendet `patterns`, die mit dem Namen einer Abhängigkeit (oder mehreren) übereinstimmen, um Abhängigkeiten in die Gruppe einzuschließen\n* Verwendet `exclude-patterns`, die mit dem Namen einer Abhängigkeit (oder mehreren) übereinstimmen, um Abhängigkeiten aus der Gruppe auszuschließen\n* Wendet die Gruppierung nur auf Versionsupdates an, da `applies-to: version-updates` verwendet wird.\n\n```yaml\nversion: 2\nupdates:\n  # Keep bundler dependencies up to date\n  - package-ecosystem: \"bundler\"\n    directories:\n      - \"/frontend\"\n      - \"/backend\"\n      - \"/admin\"\n\n    schedule:\n      interval: \"weekly\"\n    # Create a group of dependencies to be updated together in one pull request\n    groups:\n      # Specify a name for the group, which will be used in pull request titles\n      # and branch names\n      support-dependencies:\n        # Define patterns to include dependencies in the group (based on\n        # dependency name)\n        applies-to: version-updates # Applies the group rule to version updates\n        patterns:\n          - \"rubocop\" # A single dependency name\n          - \"rspec*\"  # A wildcard string that matches multiple dependency names\n          - \"*\"       # A wildcard that matches all dependencies in the package\n                      # ecosystem. Note: using \"*\" may open a large pull request\n        # Define patterns to exclude dependencies from the group (based on\n        # dependency name)\n        exclude-patterns:\n          - \"gc_ruboconfig\"\n          - \"gocardless-*\"\n```\n\nInfolgedessen:\n\n* Die meisten Abhängigkeiten für Bundler werden aufgrund des Platzhaltermusters (\"\\*\") in der Gruppe `support-dependencies` konsolidiert, abgesehen von\n* Abhängigkeiten, die mit `gc_ruboconfig` und `gocardless-*` übereinstimmen, werden aus der Gruppe ausgeschlossen, und Dependabot löst weiterhin einzelne Pull Requests für diese Abhängigkeiten aus. Dies kann hilfreich sein, wenn Updates für diese Abhängigkeiten genauer überprüft werden müssen.\n* Für `support-dependencies` werden von Dependabot nur Pull Requests für Versionsupdates ausgelöst.\n\n### Beispiel 3: Einzelne Pull Requests für Hauptversionsupdates und gruppiert für Nebenversions-/Patchupdates\n\nIn diesem Beispiel hat die Datei `dependabot.yml` folgende Funktion:\n\n* Erstellt eine Gruppe namens „`angular`“.\n* Verwendet `patterns`, die mit dem Namen einer Abhängigkeit übereinstimmen, um Abhängigkeiten in die Gruppe einzuschließen\n* Verwendet `update-type`, um nur `minor`- oder `patch`-Updates in die Gruppen einzubeziehen.\n* Wendet die Gruppierung nur auf Versionsupdates an, da `applies-to: version-updates` verwendet wird.\n\n```yaml\nversion: 2\nupdates:\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      # Specify a name for the group, which will be used in pull request titles\n      # and branch names\n      angular:\n        applies-to: version-updates\n        patterns:\n          - \"@angular*\"\n        update-types:\n          - \"minor\"\n          - \"patch\"\n```\n\nInfolgedessen:\n\n* Dependabot erstellt einen gruppierte Pull Request für alle Angular-Abhängigkeiten, die über ein Nebenversions- oder Patchupdate verfügen.\n* Alle Hauptversionsupdates werden weiterhin als einzelne Pull Requests ausgelöst.\n\n### Beispiel 4: Gruppierte Pull Requests für Nebenversions-/Patchupdates und keine Pull Requests für Hauptversionsupdates\n\nIn diesem Beispiel hat die Datei `dependabot.yml` folgende Funktion:\n\n* Erstellt zwei Gruppen namens `angular` und `minor-and-patch`\n* Verwendet `applies-to`, sodass die erste Gruppe nur für Versionsupdates und die zweite Gruppe nur für Sicherheitsupdates gilt.\n* Verwendet `update-type`, um nur `minor`- oder `patch`-Updates für beide Gruppen einzuschließen\n* Verwendet eine `ignore`-Bedingung, um Updates für `major`-Versionen von `@angular*`-Paketen auszuschließen\n\n```yaml\nversion: 2\nupdates:\n  # Keep npm dependencies up to date\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      angular:\n        applies-to: version-updates\n        patterns:\n          - \"@angular*\"\n        update-types:\n          - \"minor\"\n          - \"patch\"\n      minor-and-patch:\n        applies-to: security-updates\n        patterns:\n          - \"@angular*\"\n        update-types:\n          - \"patch\"\n          - \"minor\"\n    ignore:\n      - dependency-name: \"@angular*\"\n        update-types: [\"version-update:semver-major\"]\n```\n\nInfolgedessen:\n\n* Neben- und Patchversionsupdates für Angular-Abhängigkeiten werden in einem einzigen Pull Request gruppiert.\n* Neben- und Patchsicherheitsupdates für Angular-Abhängigkeiten werden ebenfalls in einem einzigen Pull Request gruppiert.\n* Dependabot öffnet keine automatischen Pull Requests für Angular-Hauptversionsupdates.\n\n### Gruppierung von Aktualisierungen über Verzeichnisse hinweg in einer Monorepo\n\nWenn Sie ein Monorepo mit mehreren Verzeichnissen verwalten, die gemeinsame Abhängigkeiten gemeinsam nutzen, können Sie die Anzahl der Pullanforderungen für Versionsupdates reduzieren, indem Sie Updates nach Abhängigkeitsnamen in allen Verzeichnissen gruppieren.\n\nWenn Sie Dependabot so konfigurieren, um mehrere Verzeichnisse zu überwachen und die Gruppierung nach Abhängigkeitsnamen zu aktivieren, wird Dependabot:\n\n* Erstellen einer einzelnen Pullanforderung für jedes Abhängigkeitsupdate, das sich auf mehrere Verzeichnisse auswirkt\n* Aktualisieren der gleichen Abhängigkeit auf dieselbe Version in allen Verzeichnissen in einem Vorgang\n* Verringern Sie die Anzahl der Pullanforderungen, die Sie überprüfen müssen.\n* Minimieren Sie CI/CD-Kosten, indem Sie Tests einmal anstelle pro Verzeichnis ausführen\n\nWeitere Informationen finden Sie unter [`group-by`](/de/code-security/reference/supply-chain-security/dependabot-options-reference#group-by-groups).\n\nIn diesem Konfigurationsbeispiel werden Aktualisierungen nach Abhängigkeitsnamen über die Verzeichnisse `/frontend`, `/admin-panel` und `/mobile-app` hinweg gruppiert. Wenn `lodash` in allen drei Verzeichnissen aktualisiert werden muss, erstellt Dependabot eine einzige Pull-Anfrage mit dem Namen „Bump lodash in monorepo-dependencies group“, die `lodash` an allen drei Orten aktualisiert.\n\n```yaml\nversion: 2\nupdates:\n  - package-ecosystem: \"npm\"\n    directories:\n      - \"/frontend\"\n      - \"/admin-panel\"\n      - \"/mobile-app\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      monorepo-dependencies:\n        group-by: dependency-name\n```"}