Rhythmus für Abhängigkeits-Updates: Batching, Gruppierung und was auf einmal gemergt wird

Worum es geht

Abhängigkeits-Updates treffen als Strom ein: Patch-Releases, Minor-Versionen, Majors und Sicherheitshinweise. Update-Bots verwandeln jedes davon in einen Pull Request. Die GitHub-Referenz für dependabot.yml dokumentiert schedule.interval (täglich, wöchentlich, monatlich, quartalsweise, halbjährlich, jährlich oder Cron) sowie eine groups-Option, die mehrere Updates zu einem Pull Request zusammenfasst; Renovates Leitfaden zur Lärmreduktion beschreibt Paketgruppierung, Scheduling und Automerging für denselben Zweck und hält fest, dass mit Standardeinstellungen jedes Mal ein PR erstellt wird, wenn irgendeine Abhängigkeit irgendein Update erhält. Semantic Versioning erhöht MAJOR bei inkompatiblen API-Änderungen, MINOR bei abwärtskompatibler Funktionalität und PATCH bei abwärtskompatiblen Fixes, was die Grundlage bildet, um Updates nach Risikoklassen zu sortieren.

Warum es wichtig ist

Ein Pull Request pro Patch-Release trainiert Reviewerinnen entweder darauf, ungelesen zu mergen, oder den Bot zu ignorieren; beide Wege enden Monate später in einem grossen, riskanten Nachhol-Upgrade. Ein Rhythmus mit Batches hält den Prüfaufwand proportional zum Risiko und die Lock-Datei in Bewegung.

So wird es angewendet

• Drei Spuren. Sicherheitshinweise werden geprüft und gemergt, sobald sie eintreffen, ausserhalb des Zeitplans. Patch- und Minor-Updates werden an einem festen Tag zu einem Batch gebündelt. Major-Updates erhalten einen eigenen Pull Request und ein Ticket, weil sie meist Codeänderungen brauchen.
• Das Batch-Intervall nach dem Vertrauen in die Tests wählen: wöchentlich, wenn die Suite eine Regression abfangen würde, monatlich, wenn das Mergen manuelle Prüfung braucht. Ein monatlicher Batch ist grösser, aber weiterhin begrenzt.
• Nach Familie gruppieren (alle @types/*, das gesamte Test-Tooling, die Pakete eines Frameworks), nicht nach allem. Renovates Leitfaden nennt den Kompromiss: Ein gruppierter Branch scheitert eher, es dauert länger herauszufinden, welches Paket ihn zum Scheitern gebracht hat, und eine fehlschlagende Gruppe hält jedes andere Update darin auf.
• Nur die Klasse automatisch mergen, deren Fehlschlag die Tests erkennen würden, nachdem die CI durchgelaufen ist; beim Rest einen Menschen einbeziehen.
• Den Bot die Lock-Datei aktualisieren lassen; ihr Diff zeigt dann genau, welche transitiven Pakete sich bewegt haben.
• Vor dem Einplanen eines Updates, das eine Major-Grenze überschreitet, dessen Changelog lesen; dort angekündigte Deprecations sind die Arbeit des nächsten Batches.

Stolpersteine

Pull Requests, die zu jeder Stunde eintreffen, unterbrechen Arbeitstage; Renovates Leitfaden merkt an, dass viele Nutzerinnen seinen Zeitplan auf ausserhalb der normalen Arbeitszeit beschränken, etwa auf Wochennächte und Wochenenden. Ein gruppierter Batch, der die CI nicht besteht, sollte aufgeteilt, nicht rot gemergt werden. Ökosysteme, die keinem Semantic Versioning folgen (Kalenderversionen, 0.x-Pakete), brauchen Beurteilung pro Paket, und auch ein Patch-Release kann einen Build noch brechen.

Ein Mindestalter für Releases vor dem Automerge

Ein grüner Testlauf zeigt, dass ein Update kompatibel ist, nicht, dass es sicher ist: Die vielfach dokumentierten npm-Kompromittierungen von 2018, 2021 und 2025 wurden als gewöhnliche Patch- oder Minor-Versionen ausgeliefert, die die Tests ihrer Konsumentinnen bestanden, und die meisten wurden innerhalb von Stunden oder Tagen aus der Registry zurückgezogen. Den automatisch gemergten Spuren eine Wartezeit hinzufügen: Renovates minimumReleaseAge, Dependabots cooldown (mit default-days und Werten je Semver-Stufe) oder pnpms minimumReleaseAge zur Installationszeit, gesetzt auf einige Tage. Die Sicherheitsspur bleibt davon ausgenommen, da ein Fix für einen Sicherheitshinweis das eine Release ist, das sofort landen sollte. Batches enthalten dann nur Versionen, die die Frist öffentlich überstanden haben, und die Prüfung in der Major-Spur bleibt unverändert.