Abhängigkeiten aktuell halten: 7 Regeln gegen Update-Stress

Für ein kleines Team ist ein guter Ausgangspunkt: normale Versionsupdates einmal pro Woche bündeln, höchstens drei davon gleichzeitig offen halten und Major-Updates einzeln behandeln. Das ist ein redaktioneller Startwert, kein Branchenstandard. Wenn drei Pull Requests regelmäßig liegen bleiben, ist nicht der Bot zu langsam, sondern die Review-Kapazität zu knapp oder die Gruppierung ungeeignet.

1. Sicherheitsupdates bekommen eine eigene Spur

Sicherheitsupdates und normale Versionsupdates verfolgen unterschiedliche Ziele. Bei Dependabot werden Security-Updates durch bekannte Schwachstellen ausgelöst; der Zeitplan in dependabot.yml steuert dagegen die regulären Versionsprüfungen. Deshalb sollte ein wöchentliches Wartungsfenster keine Sicherheitsmeldung bis zum nächsten Termin parken.

Praktisch bedeutet das:

• Sicherheitsmeldungen separat kennzeichnen und nach Ausnutzbarkeit, betroffener Laufzeit und Exposition bewerten.
• Einen technischen Verantwortlichen benennen, der die Auswirkung prüft und die Reaktion koordiniert.
• Auch einen Sicherheits-Pull-Request testen. „Vom Bot erzeugt“ bedeutet nicht „für die eigene Anwendung risikofrei“.
• Gruppierte Sicherheitsupdates nur dann gemeinsam behandeln, wenn die gemeinsame Änderung noch nachvollziehbar und testbar bleibt.

GitHub kann Sicherheitsupdates pro Paket-Ökosystem gruppieren, mischt sie aber nicht mit normalen Versionsupdates. Diese Trennung ist eine brauchbare Vorlage für den eigenen Arbeitsablauf.

2. Dependabot oder Renovate: Das Betriebsmodell entscheidet

Beide Werkzeuge erkennen veraltete Abhängigkeiten und erzeugen Änderungsvorschläge. Der wichtigste Unterschied für kleine Teams liegt weniger im Grundzweck als in der Umgebung und im gewünschten Steuerungsgrad.

Dependabot liegt nahe, wenn die Repositories auf GitHub liegen und das Team eine GitHub-native Konfiguration in .github/dependabot.yml bevorzugt. Zeitplan, Gruppen, Limits, Labels und Reviewer lassen sich dort festlegen.

Renovate passt eher, wenn mehrere Git-Plattformen unterstützt, Regeln zentral als Presets verteilt oder Updates über ein Dependency Dashboard sichtbar freigegeben werden sollen. Renovate unterstützt unter anderem GitHub, GitLab, Bitbucket, Azure, Forgejo und Gitea; einzelne Funktionen unterscheiden sich je nach Plattform.

Es gibt keinen pauschalen Sieger. Entscheidend ist, welches Werkzeug das Team dauerhaft versteht und betreibt. Zwei Bots sollten nicht parallel dieselbe Paketgruppe verwalten, weil die Zuständigkeit sonst unnötig unklar wird.

3. Ein fester Takt ersetzt Dauerunterbrechung

Neue Versionen müssen nicht zwangsläufig in dem Moment als Pull Request erscheinen, in dem sie veröffentlicht werden. Dependabot unterstützt planbare Intervalle und Zeitpunkte; Renovate kann Ausführung und Automerge ebenfalls über Zeitfenster steuern.

Für viele kleine Teams ist ein wöchentlicher Termin für normale Minor- und Patch-Updates ein vernünftiger Start. Legen Sie den Bot-Lauf so, dass die Vorschläge kurz vor dem vereinbarten Triage-Termin eintreffen. Sicherheitsmeldungen bleiben davon getrennt. Häufigere Läufe sind sinnvoll, wenn das Team sie tatsächlich bearbeitet; seltenere Läufe lösen keinen Rückstau, sondern verstecken ihn nur länger.

Ein fester Rhythmus braucht drei Angaben: Wer sichtet? Wann wird entschieden? Was passiert mit einem Update, das zwei Termine lang liegen bleibt? Mögliche Antworten sind Eskalation an den Repository-Owner, bewusste Verschiebung mit Begründung oder ein eigenes Migrations-Ticket.

4. Begrenzen und gruppieren – aber nach gemeinsamer Testfläche

PR-Limits schützen die Review-Queue. Gruppierung reduziert die Zahl der Pull Requests. Beides wirkt nur, wenn ein Fehler noch eindeutig eingegrenzt werden kann.

Sinnvolle Gruppen sind häufig:

• Linter, Formatter und zugehörige Plugins,
• eng gekoppelte Pakete desselben Frameworks,
• Entwicklungsabhängigkeiten, die durch dieselbe CI-Prüfung abgedeckt sind,
• Patch-Updates eines Paket-Ökosystems mit vergleichbarem Risiko.

Separat bleiben sollten Major-Updates, Laufzeit- oder Datenbanktreiber, Authentifizierungsbibliotheken und Änderungen mit unterschiedlichen Rollback-Wegen. Das ist eine risikobasierte redaktionelle Leitlinie, keine Produkteinschränkung.

Versionsnummern sind dabei nur ein Signal. Nach Semantic Versioning steht MAJOR.MINOR.PATCH für inkompatible API-Änderungen, rückwärtskompatible Funktionen und rückwärtskompatible Fehlerkorrekturen. Diese Bedeutung gilt aber nur, wenn ein Projekt Semantic Versioning tatsächlich einhält; bei 0.y.z darf sich laut Spezifikation jederzeit etwas ändern. Changelog, Release Notes und eigene Tests bleiben daher wichtiger als das Label „Patch“.

5. Automerge bleibt eine eng begrenzte Ausnahme

Automerge spart nur dann Arbeit, wenn die Prüfungen einen relevanten Fehler zuverlässig erkennen. Renovate lässt Automerge bewusst als Opt-in und wartet bei Pull-Request-Automerge auf grüne, aktuelle Statusprüfungen. Das ersetzt weder gute Tests noch Schutzregeln für den Zielbranch.

Beginnen Sie mit deaktiviertem Automerge. Aktivieren Sie es später nur für klar definierte Paket- und Updateklassen, wenn:

• die verpflichtenden CI-Prüfungen stabil und für den betroffenen Code aussagekräftig sind,
• der Zielbranch direkte, ungeprüfte Änderungen verhindert,
• das Update keine manuelle Migration oder Konfigurationsänderung verlangt,
• ein fehlgeschlagener Rollout schnell erkannt und zurückgenommen werden kann.

Major-Updates und Pakete mit schwacher oder unzuverlässiger Versionsdisziplin gehören nicht in diese Regel. Ein grüner Build belegt nur, was die vorhandenen Tests abdecken.

6. Major-Updates werden zu kleinen Migrationsprojekten

Ein Major-Update sollte nicht zwischen Routine-Patches verschwinden. Planen Sie es als eigene Änderung mit klarer Entscheidung:

1. Release Notes und Migrationshinweise lesen.
2. Betroffene APIs, Laufzeitversionen und Peer Dependencies bestimmen.
3. Tests ergänzen, die genau diese Änderungen abdecken.
4. Staging oder einen begrenzten Rollout nutzen, wenn das System dies ermöglicht.
5. Einen Rückweg festlegen, bevor die Änderung produktiv geht.

Bei lange zurückgestellten Major-Versionen hilft ein sichtbares Ticket mit Owner und nächstem Prüftermin. Permanentes Ignorieren beseitigt das Risiko nicht; es verschiebt nur die Entscheidung.

7. Messen, ob der Prozess wirklich ruhiger wird

Die Zahl erzeugter Pull Requests ist keine Erfolgsmetrik. Beobachten Sie stattdessen monatlich:

• Alter offener Updates, getrennt nach Sicherheits- und Versionsupdates,
• Zeit von einer relevanten Sicherheitsmeldung bis zur geprüften Behebung,
• Anteil fehlgeschlagener oder zurückgenommener Dependency-Updates,
• manuelle Review-Zeit und Zahl gleichzeitig offener Update-Pull-Requests,
• bewusst zurückgestellte Major-Updates mit Owner und nächstem Termin.

Vergleichen Sie diese Werte zunächst mit der eigenen Ausgangslage. Universelle Grenzwerte wären irreführend, weil Testabdeckung, Release-Risiko und Teamgröße stark variieren. Wenn die Queue wächst, ändern Sie zuerst Takt, Gruppierung oder Zuständigkeit – nicht automatisch die Zahl der Bot-Läufe.

Eine konservative Startkonfiguration für kleine Teams

• Normale Updates: ein fester wöchentlicher Triage-Termin.
• Parallele Arbeit: zunächst höchstens drei offene Versionsupdate-PRs pro Repository.
• Sicherheitsmeldungen: außerhalb des Wochenbatches zeitnah nach internem Risiko bewerten.
• Gruppen: nur Änderungen mit gemeinsamer Testfläche; Major-Versionen einzeln.
• Automerge: zunächst aus, danach schrittweise nur für klar begrenzte risikoarme Klassen.
• Verantwortung: ein Owner pro Repository und eine Vertretung.
• Nachsteuerung: nach vier Wochen prüfen, ob Alter, Fehlerrate und Review-Aufwand sinken.

Der entscheidende Punkt ist nicht maximale Automatisierung. Ein gutes Update-System erzeugt genau so viele überprüfbare Änderungen, wie das Team sicher entscheiden und ausrollen kann.