Updates, die sich selbst vorschlagen: Abhängigkeiten mit Renovate

Beim Patchen denkt man an das Betriebssystem. Aber unter jeder Anwendung liegt eine zweite Schicht, die genauso altert: Base-Images, Chart-Versionen, Bibliotheken, Action-Versionen. Die aktualisiert kaum jemand systematisch, weil es Handarbeit ist. Renovate macht daraus einen Prozess. Ich zeige hier der Reihe nach, was der Bot bei mir findet, wie ein Update daraus zu einem getesteten Merge Request wird, wie ich das bis in die Cluster-Infrastruktur ziehe - und woran das Ganze scheitert, wenn ein Baustein fehlt.

Schritt 1: Renovate findet mehr als die package.json

Bevor Renovate irgendetwas verändert, liest er das Repo einmal komplett aus. Ein Trockenlauf gegen mein eigenes Website-Repo zeigt, wie breit dieser Blick ist:

55 Abhängigkeiten über fünf verschiedene Manager, aus einem kleinen Repo: nicht nur die npm-Pakete, sondern auch die Base-Image-Tags im Dockerfile, die Versionen in den GitHub-Actions, die Node-Version im .nvmrc. Genau die Stellen, die man von Hand vergisst. Jeder dieser Dateitypen wird von einem eigenen Manager erkannt, ohne dass ich pro Datei etwas konfigurieren muss.

Schritt 2: Ein Update, ein Merge Request

Der eigentliche Gewinn ist der Ablauf, der jetzt folgt. Statt „irgendwann mal aktualisieren“ öffnet Renovate für jedes verfügbare Update einen Merge Request, mit Changelog-Link, und die CI-Pipeline testet ihn sofort. Ist der MR grün, ist das Update belegt verträglich und wird gemergt. Ist er rot, weiß man das, bevor das Update in Produktion läuft, nicht danach.

Schritt 3: In GitOps auch die Infrastruktur-Version

Dasselbe Prinzip lässt sich bis in die Infrastruktur ziehen. In einem GitOps-Setup steht die gewünschte Cluster-Version als Text im Repo, und ArgoCD gleicht den laufenden Cluster laufend gegen diesen Stand ab. Ich habe Renovate so konfiguriert, dass es das Feld targetRevision der ArgoCD-Applications anhebt, also die Versionen der externen Helm-Charts, aus denen der Cluster gebaut ist. Über eine Pipeline im Repo mit eigenem Runner wird so selbst „welche Chart-Version läuft“ zu einem überprüften Merge Request statt zu einer stillen Handänderung.

Der Betrieb: Renovate ohne CI ist gefährlich

Ein ehrlicher Vorbehalt zum Schluss. Automatische Update-MRs, die niemand testet und die blind gemergt werden, sind schlimmer als gar keine Updates. Der Wert entsteht erst aus dem Paar: Renovate schlägt vor, die CI beweist, dass es weiter läuft.

Und man muss den Lärm drosseln. 55 Abhängigkeiten, die alle einzeln MRs werfen, überfordern jedes Team. Gruppierung, Zeitfenster und automatisches Mergen für unkritische Patches sind Pflicht, sonst ertrinkt man in Vorschlägen und schaltet Renovate genervt wieder ab.

Wie das Aktualisieren am Ende verlässlich und dokumentiert läuft, habe ich im Beitrag Patch-Management mit Ansible beschrieben.

Sie wollen Ihre Abhängigkeiten aktuell halten, ohne dass es zur Daueraufgabe wird? Ich baue automatisierte Update-Strecken, in denen jede Änderung erst getestet und dann übernommen wird. Mehr unter IT-Automatisierung, das Erstgespräch ist unverbindlich.