guides

Beide Werkzeuge tun nach außen dasselbe: Sie beobachten Ihre Abhängigkeiten, bemerken eine neue Version und öffnen einen Pull Request. Wäre das alles, wäre die Wahl egal. Sie zählt wegen dessen, was danach passiert, wenn zwanzig solcher Pull Requests offen sind, und die beiden Werkzeuge vertreten zu diesem Problem entgegengesetzte Positionen.

Dependabot ist das, was Sie schon haben. Es ist in GitHub eingebaut, kostet nichts, und das Einschalten ist eine Datei `.github/dependabot.yml` mit etwa sechs Zeilen. Kein Konto anzulegen, keine App zu installieren, kein Runner zu betreiben. Für ein Repository, das heute gar keine Automatisierung hat, ist das der kürzeste Weg zu einer.

Renovate ist das, zu dem man wechselt, wenn die Pull Requests selbst zum Problem werden. Es ist Open Source, läuft als gehostete App, selbst gehostet oder in Ihrer eigenen CI und funktioniert mit GitLab, Bitbucket und Azure DevOps ebenso wie mit GitHub. Seine Konfiguration ist eher eine Regel-Engine als eine Einstellungsdatei, und das ist zugleich sein Vorteil und sein Preis.

Die eigentliche Trennlinie sind Gruppierung und Lärm. Ein Projekt mit vierzig Abhängigkeiten erzeugt viele einzelne Versionssprünge, und sie einzeln zu prüfen ist Arbeit, die sich wie Wartung anfühlt, ohne es zu sein. Dependabot hat gruppierte Updates hinzugefügt, und sie helfen. Die `packageRules` von Renovate bleiben deutlich ausdrucksstärker: nach Paketmuster, Update-Typ oder Verzeichnis gruppieren, jeder Gruppe einen eigenen Zeitplan geben, Patch-Updates von Entwicklungsabhängigkeiten automatisch mergen und Major-Versionen zur Prüfung zurückhalten. Wenn Sie über das *Volumen* klagen, kaufen Sie genau diese Ausdruckskraft.

Die Zeitplanung ist der zweite spürbare Unterschied. Bei Renovate legen Sie fest, wann Updates erscheinen dürfen (außerhalb der Bürozeiten, an einem bestimmten Tag, höchstens so oft) mit Regeln, die je Gruppe verschieden sind. Der Zeitplan von Dependabot ist einfacher. In einem kleinen Repository ist einfach ein Vorteil; in einem viel genutzten heißt es, dass die PRs kommen, wann sie kommen.

Das Dependency Dashboard ist die unterschätzte Funktion von Renovate. Es öffnet im Repository ein einziges Issue mit allem, was es tun möchte, einschließlich dessen, wofür es bewusst keinen PR geöffnet hat. Sie sehen den Stand Ihrer Abhängigkeitsschulden auf einer Seite, statt ihn aus einem Posteingang zu erschließen. In Dependabot gibt es nichts Entsprechendes.

Wo Dependabot wirklich vorn liegt: Sicherheitswarnungen. Der Teil für Versionsupdates ist nur die Hälfte des Produkts. Die andere Hälfte hängt an der Sicherheitsdatenbank von GitHub und meldet verwundbare Abhängigkeiten als Warnungen, mit reinen Sicherheitsupdates, die sich unabhängig von Versionsupdates einschalten lassen. Renovate kann ebenfalls auf Schwachstellen reagieren, aber wenn Ihre Priorität *die Sicherheitslage innerhalb von GitHub* ist, ist Dependabot der native Weg, und er dauert Minuten.

Die Plattform ist die Antwort, wenn sie die Antwort ist. Liegt Ihr Code nicht auf GitHub, endet der Vergleich hier: Renovate ist das Werkzeug, das dort läuft, wo Sie sind. Und wenn Updates aus Ihrer eigenen Infrastruktur statt aus einer Drittanbieter-App kommen sollen, lässt sich Renovate selbst hosten; diese Option gibt es auf der anderen Seite nicht.

Der Konfigurationsaufwand ist real und sollte offen gesagt werden. Die Flexibilität von Renovate kommt aus einem Schema, das so groß ist, dass die meisten von einem Preset ausgehen und es anpassen. Rechnen Sie mit einem Nachmittag, bis es sich so verhält, wie Sie wollen, und rechnen Sie damit, wieder daran zu arbeiten. Dependabot konfigurieren Sie auf Anhieb richtig, weil es weniger falsch zu machen gibt. Das ist ein echtes Argument dafür, kein Trostpreis.

Ein vernünftiger Standard: Beginnen Sie mit Dependabot, vor allem für Sicherheitsupdates. Wechseln Sie zu Renovate, wenn Sie benennen können, was Sie konkret stört: zu viele PRs, falscher Zeitpunkt, keine Gruppierung, nicht auf GitHub, Bedarf an Auto-Merge-Regeln. Später zu migrieren ist billig. Eine Regel-Engine zu konfigurieren, bevor man das Problem hat, das sie löst, führt dazu, dass man seine Abhängigkeitsautomatisierung pflegt statt seines Projekts.

Egal, was Sie wählen: Das Werkzeug schlägt nur vor. Was Sie wirklich schützt, ist dasselbe, was diese Werkzeuge erst möglich gemacht hat: ein committetes Lockfile, damit die vom Bot vorgeschlagene Version auch die ist, die Ihre CI installiert hat, und eine Testsuite, die gut genug ist, damit ein grüner Pull Request etwas bedeutet.