Wartungshölle vermeiden: Automatisierte Updates mit Renovate & Dependabot

Wartungshölle vermeiden: Automatisierte Updates mit Renovate & Dependabot

Update (Juli 2026): Dieser Artikel wurde überarbeitet und aktualisiert – unter anderem mit einer klareren Analyse des Kernproblems und einem konkreten Weg heraus, falls ihr bereits mittendrin steckt.

Jeder Entwickler kennt die Szene: Ein Projekt läuft seit Monaten unangetastet, weil es "fertig" ist und niemand es anfassen wollte. Dann kommt der Tag, an dem sich etwas ändern muss – ein neues Feature, ein Security-Audit, ein Wechsel der Node-Version. Man führt npm install aus, und plötzlich bricht die halbe Build-Pipeline zusammen. Zwischen der eigenen Version und dem, was die Libraries mittlerweile erwarten, liegen zwei Jahre und zwanzig Major-Releases.

Willkommen in der Wartungshölle (Dependency Hell).

Das eigentliche Problem: Nicht die Updates, sondern die Lücke

Der verbreitete Reflex ist, das Problem als "wir haben zu selten aktualisiert" zu beschreiben. Das ist aber nur das Symptom. Das eigentliche Problem ist die Lücke zwischen Änderungsrate und Reaktionsrate.

Software-Abhängigkeiten ändern sich kontinuierlich – jede Woche erscheinen irgendwo Patches, Security-Fixes, neue Major-Versionen. Das ist normal und unvermeidbar. Das Problem entsteht erst, wenn ein Projekt darauf nicht kontinuierlich reagiert, sondern in Schüben: gar nicht, gar nicht, gar nicht – und dann alles auf einmal.

Diese Lücke wächst nicht linear, sondern exponentiell, aus drei Gründen:

• Breaking Changes stapeln sich. Ein Update von Version 1.0 auf 1.1 ist meist trivial. Zehn übersprungene Major-Versionen bedeuten aber zehn verschiedene, sich teils widersprechende Migrationspfade gleichzeitig.
• Kontext geht verloren. Wer vor zwei Jahren entschieden hat, warum genau diese Library-Version gepinnt wurde, ist oft nicht mehr im Team – oder erinnert sich nicht mehr.
• Die Angst wächst mit der Lücke. Je größer der Rückstand, desto riskanter fühlt sich jedes einzelne Update an, desto eher wird es weiter aufgeschoben. Ein Teufelskreis.

Am Ende steht man vor einer Entscheidung, die sich falsch anfühlt, aber oft die einzig sinnvolle ist: ein "Big Bang"-Update-Projekt, das Tage oder Wochen bindet – Zeit, die niemand eingeplant hatte, für Arbeit, die keinen sichtbaren neuen Wert schafft.

Warum das mehr als ein Zeitproblem ist

Neben dem reinen Aufwand hat aufgeschobene Wartung zwei konkrete Kosten:

1. Sicherheitsrisiko. Bekannte Schwachstellen (CVEs) in alten Paketversionen sind öffentlich dokumentiert – wer sie nicht schließt, bietet eine offene Angriffsfläche, die jeder mit einem Scanner finden kann.
2. Handlungsunfähigkeit. Ein Projekt, das man aus Angst vor kaputten Dependencies nicht anfassen will, kann auch fachlich nicht mehr weiterentwickelt werden. Die technische Schuld bremst nicht nur Updates, sondern jedes neue Feature.

Der Weg raus: Wenn ihr schon mittendrin steckt

Falls euer Projekt die Lücke bereits hat – und das ist der häufigere Ausgangspunkt als ein sauberes neues Projekt – hilft es nicht, direkt einen Bot zu installieren und zu hoffen. Erst muss die Lücke geschlossen werden, dann kann Automatisierung sie klein halten.

1. Bestandsaufnahme statt Bauchgefühl. Lasst npm outdated, pnpm outdated oder einen Security-Scan (z. B. npm audit, Snyk) laufen. Ihr braucht eine Liste, keine Vermutung, wie groß die Lücke wirklich ist.
2. Sicherheitslücken zuerst, isoliert von allem anderen. Kritische CVEs schließt ihr sofort und einzeln – nicht im selben Zug wie funktionale Updates. Das begrenzt das Risiko, wenn beim Update selbst etwas schiefgeht.
3. In Wellen statt in einem Rutsch aktualisieren. Geht Major-Version für Major-Version vor, nicht direkt von 2 auf 9. Nach jeder Welle: testen, deployen, kurz beobachten. Das macht Fehlerquellen eingrenzbar.
4. Ein Sicherheitsnetz vor dem ersten Update bauen. Ohne automatisierte Tests ist jedes Update ein Blindflug – dazu gleich mehr.
5. Erst danach automatisieren. Sobald die Lücke geschlossen ist, verhindert ihr mit Renovate oder Dependabot, dass sie sich erneut aufbaut.

Der Aufholprozess ist unangenehm, aber einmalig. Die Alternative – weiter warten – macht ihn nur teurer.

Der Weg, die Lücke nicht wieder aufzubauen: Automatisierung

Sobald der Rückstand aufgeholt ist, ist die eigentliche Lösung simpel: Updates dürfen nie wieder in großen Schüben passieren, sondern müssen kontinuierlich und in kleinen Häppchen reinkommen. Genau dafür gibt es Bots.

1. Dependabot (Der GitHub-Standard)

Dependabot gehört mittlerweile zu GitHub und ist dort tief integriert. Er ist der einfachste Einstieg.

Vorteile:

• Zero-Config für Sicherheitsupdates (Security Alerts).
• Einfache Konfiguration über eine dependabot.yml.
• Native Integration in die GitHub UI.

Nachteile:

• Weniger Konfigurationsmöglichkeiten als Renovate.
• Erstellt oft sehr viele einzelne Pull Requests (PRs), was "Noise" erzeugen kann.

2. Renovate (Der Power-User)

Renovate ist ein extrem mächtiges Open-Source-Tool, das auf fast jeder Plattform läuft (GitHub, GitLab, Bitbucket, Azure DevOps).

Vorteile:

• Extrem konfigurierbar: Du kannst genau steuern, wann welche Updates kommen.
• Grouping: Renovate kann Updates zusammenfassen (z.B. "alle Non-Major Updates einmal pro Woche"). Das reduziert den Lärm im Posteingang massiv.
• Auto-Merge: Wenn Tests grün sind, kann Renovate Updates (z.B. für Dev-Dependencies oder Patches) automatisch mergen.
• Dashboard: Ein Issue im Repo gibt dir jederzeit Übersicht über anstehende Updates.

Nachteile:

• Die Konfiguration (renovate.json) kann am Anfang überwältigend sein.

---

Best Practices, damit die Lücke nicht zurückkommt

Egal für welches Tool du dich entscheidest, hier sind Strategien, damit du nicht von PRs erschlagen wirst – und die Lücke nicht schleichend wieder wächst:

1. Gute Testabdeckung ist Pflicht: Ohne Tests sind automatische Updates Russisch Roulette. Dein CI/CD-System muss dir vertrauenswürdig sagen: "Es läuft noch."
2. Gruppiere Updates: Lass dir nicht für jeden kleinen Patch eine E-Mail schicken. Gruppiere z.B. alle eslint-Plugins oder alle Minor-Updates zusammen.
3. Auto-Merge für Vertrauenswürdiges: Patches und Minor-Updates von stabilen Libraries (wie Lodash oder Prettier) kannst du oft automatisch mergen lassen, wenn die CI grün ist.
4. Schedule: Lass Updates z.B. nur am Montagmorgen oder am Wochenende laufen, damit du unter der Woche fokussiert arbeiten kannst.
5. Major-Updates bewusst planen: Anders als Patches solltest du Major-Versionen nicht blind automerge lassen. Plane sie als kleine, bewusste Aufgabe ein, statt sie sich wieder anstauen zu lassen.

Fazit

Die "Wartungshölle" ist kein Schicksal, sondern das Ergebnis einer Lücke zwischen dem Tempo, in dem sich Abhängigkeiten ändern, und dem Tempo, in dem ein Team darauf reagiert. Diese Lücke schließt sich nicht von selbst – sie muss aktiv beseitigt (falls schon vorhanden) und dauerhaft klein gehalten werden (durch Automatisierung).

Mit Tools wie Renovate oder Dependabot machst du genau das: Dependency-Updates werden zu einem langweiligen Hintergrundprozess statt zu einem angstbesetzten Großprojekt.

Mein Tipp: Starte mit Renovate. Die Lernkurve ist etwas steiler, aber die Ruhe, die du durch intelligentes Grouping und Scheduling gewinnst, ist es wert.