Wie Turbine Kreuzberg den „Renovate Bot“ einsetzt Über die Vorteile automatisierter Updates

Anbieter zum Thema

Windhoff Group

Das Aufspielen von Updates, sei es für Frontend- oder Backend-Packages, ist eine mühselige Aufgabe. Dabei sind regelmäßige Aktualisierungen wichtig, beispielsweise um Sicherheitslücken zu schließen. Wie sich diese Aufgabe automatisieren lässt, haben wir mit Ben Kuhn, Developer bei Turbine Kreuzberg, im Gespräch erörtert.

Dev-Insider: Hallo Herr Kuhn, Automatisierung ist mittlerweile in fast jedem Schritt der Software-Entwicklung und -Bereitstellung zu finden. Bei Turbine Kreuzberg habt ihr nun selbst den Update-Prozess automatisiert. Warum war euch das so wichtig?

Ben Kuhn: Gerade im Entwicklungsprozess bei der Arbeit mit Auftragsprojekten wird oft der Fokus auf das Hinzufügen von neuen Features gelegt, das Maintaining der Software aber wird vernachlässigt. Das führt zur Veraltung der Software und kann extrem kritisch werden. Veraltete Software kann beispielsweise Sicherheitslücken aufweisen, die eigentlich schon mit einem einfachen Update gefixt wurden.

Eine weitere Sache, die man bedenken muss: Wenn Updates lange nicht gemacht wurden, steigt die Wahrscheinlichkeit, dass man sie nicht einfach so einspielen kann. Je größer die Lücke zwischen zwei Versionen ist, desto schwieriger wird es. Genau das ist eine der Stärken automatisierter Update-Tools. Sie lassen die „Lücke” nicht zu groß werden. Sie schaffen Awareness und so auch Sicherheit.

Darüber hinaus ist das Aufsetzen eines Automatisierungs-Tools prinzipiell nicht sehr kompliziert. Herausfordernd ist es eher, die richtigen Konfigurationseinstellungen herauszufinden. Also festzulegen: Was darf automatisch gemergt werden, was nicht? Wo sollte unbedingt noch mal jemand kontrollieren? Wie viel Präsenz darf es haben? Jedes neue Update triggert ja auch Pipelines und das kostet wiederum Ressourcen, also Geld.

Dev-Insider: Wie habt ihr den automatischen Update-Prozess umgesetzt?

Kuhn: Wir nutzen für die automatische Integration von Updates ein Tool namens „Renovate Bot“. Dieser Bot geht über von dir ausgewählte Dependency-Files und überprüft, ob es Updates bezüglich der Version in diesen Files gibt. Dabei ist er sehr flexibel einrichtbar. Das heißt, er überprüft Backend-Versionen, in unserem Fall oft PHP- oder Spryker-Packages, aber auch Frontend-Packages und die Images in Docker, wo wir die grundlegenden Versionen unserer Server managen.

Dev-Insider: Wie genau geht der Bot dabei vor?

Kuhn: Er schaut sich die aktuellen Versionen an und überprüft, ob eine neuere Version verfügbar ist. Sobald das der Fall ist, öffnet er einen Merge-Request, der dann in Git sichtbar wird. Im Grunde schafft er zunächst nichts anderes als Sichtbarkeit.

Automatisiert werden mögliche Updates aufgezeigt und gegebenenfalls, abhängig davon, wie man es konfiguriert, auch automatisch gemerged. Wir arbeiten in unseren Projekten mit einer QA-Pipeline. Den Renovate-Bot kann man so einstellen, dass, wenn diese einen grünen Status besitzt, ein neues Update automatisch aufgespielt wird.

Dev-Insider: Wie wurde vor der Einführung des Tools aktualisiert?

Kuhn: Im besten Fall wird periodisch nach Updates geschaut. In der Realität sah und sieht das jedoch oft anders aus. Es ist keine Awareness da, ganz nach dem Motto: „Es funktioniert doch alles, wo ist der Need?”

Ich vergleiche es gerne mit Gesundheitsvorsorge. Man sollte sich gesund ernähren, damit man später im Alter noch gesund ist. So ähnlich ist das mit regelmäßig geupdateter Software. Schlechte Ernährung oder Rauchen ist, wie Software veralten zu lassen. Manchmal geht alles gut und der Mensch beziehungsweise das System lebt sehr lange, aber es birgt natürlich ein hohes Risiko.

Dev-Insider: Was war für euch der Anlass, den Renovate Bot in eure Projekte einzubetten?

Kuhn: Wir haben ein Projekt, das wir mittlerweile sehr lange betreuen. Daher mussten wir uns naturgemäß auch mit dem Management von Updates beschäftigen. Wir wollten einen besseren Workflow entwickeln, sind nach Recherchen mit dem Renovate Bot als Lösung gestartet und haben durchaus gute Erfahrungen gemacht.

Als wir zum ersten Mal einen Renovate Bot bei diesem Projekt eingesetzt haben, sind wir zunächst sehr defensiv vorgegangen. Am Anfang war nur automatisiert, dass ein Merge-Request aufgemacht wurde, wenn ein Update verfügbar war. Dann haben wir uns das Update angeschaut und anschließend händisch aufgespielt.

Mit der Zeit haben wir jedoch immer mehr Selbstbewusstsein in unsere Pipeline bekommen. Wenn also nur kleine Änderungen, beispielsweise im Frontend, anstanden, dann haben wir das automatisch mergen lassen. Das war ein Prozess von sehr zurückhaltend bis mittlerweile ausgesprochen selbstbewusst.

Um mal ein konkretes Beispiel zu nennen – einen Major Patch automatisch zu mergen, ohne zu wissen, was genau verändert wurde, das machen wir auch nicht. Wir haben jedoch mittlerweile herausgefunden: Je selbstbewusster wir mit unserer Pipeline sind, desto mehr können wir Minor Patches auch automatisch einpflegen lassen.

Mein Tipp für alle, die es probieren möchten: Fangt klein an und steigert euch sukzessive. Schon bei kleinen Sachen hilft der Renovate-Bot, allein schon, um zu zeigen, wie schnell das System out of date und somit potenziell gefährdet ist.

Dev-Insider: Wie schnell bekommt man „genug Selbstbewusstsein in seine Pipeline“, sodass der Bot viel Arbeit übernehmen kann?

Kuhn: Das ist ein Erfahrungswert, den man sammelt. Ansonsten bekommt man dieses Selbstbewusstsein vor allem durch ausreichende Tests: Wir wissen, was wir alles testen. Wir haben Einzel-Tests, aber auch Tests, die die komplette User Journey durch unseren Shop als Bestandteil haben. Es wird so viel getestet, dass man das händisch gar nicht nachstellen könnte.

Darüber hinaus spielt die Qualitätssicherung in der Pipeline eine große Rolle. Ist diese hoch, können viele Sachen einfach auch automatisch eingespielt werden. Dieses Selbstbewusstsein, das wir entwickelt haben, zeigt meiner Meinung nach die Qualität unseres Codes und unseres Testings. Man kann jedoch keine genauen Aussagen geben, wann man sich sicher sein kann.

Letzten Endes braucht es Projekterfahrung, um zu entscheiden, wann eine Pipeline gut genug dafür ist. Das gilt auch für den Umgang mit dem Tool: Wir haben mittlerweile viel Erfahrung gesammelt, welche Konfigurationen für uns am besten funktionieren. Das ist ein großer Vorteil bei der Einrichtung. Das geht so weit, dass wir den Bot mittlerweile von Anfang an in neue Projekte integrieren.

Das ist ein weiterer Aspekt, den man beachten muss: Ob die Einführung der automatisierten Updates bei einem Live-Projekt oder während des Aufsetzens eines neuen Projekts geschieht. Während der Ramp-up-Phase ist es schon von großem Vorteil, wenn die Software-Versionen von Anfang direkt auf dem neuesten Stand sind. Ansonsten rennt man, was Updates angeht, immer hinterher. Aber auch die Integration eines Update-Tools in ein Live-Projekt ist möglich, so war es bei uns auch.

Dev-Insider: Ganz problemlos ist die automatische Einspielung von Updates aber sicherlich nicht, oder?

Kuhn: Wenn eine neue Version inkompatibel ist, da Funktionen größere Signatur-Änderungen erhalten haben, kann schon mal ein Fehler vorkommen. Wenn jedoch ein Feature hinzukommt, sollte das nicht unbedingt direkt zu einem Fehler führen.

Das ist ein weiterer großer Vorteil des Renovate Bots: Er öffnet ja schon automatisch einen Merge-Request. So kann man sehen, es gibt ein neues Update, das mit der aktuellen Version nicht funktioniert und entsprechend reagieren. Entscheidend ist die Konfiguration. Wenn man es falsch konfiguriert, können Updates eingespielt werden, die nicht da sein sollen. Aber auch das ist eher das Problem der Qualitätssicherung in den Pipelines und nicht des Renovate Bots an sich.

Dev-Insider: Gibt es noch weitere Vorteile?

Kuhn: Das ist kein Vorteil an sich, aber wir haben gelernt, die Versions-Politik der Provider besser zu verstehen. Durch die Awareness und die Beurteilung der Versionen konnten wir oft sehen, was der Hintergedanken der Anbieter bei kleineren Update-Versionen ist.

Für das Application Management ist es ehrlich gesagt egal, wenn eine Variable anders benannt wird. Das ist für die Coding-Standards wichtig und oft der Grund kleiner Patch-Versionen. Das hat natürlich auch seine Berechtigung, Codequalität ist extrem wichtig. Aber dass sich eine Entwicklerin eine halbe Stunde anschaut, was geändert wurde, nur um zu sehen, dass eine Variable umbenannt wurde, bspw. von „Product” zu „Product Abstract” – also einfach eine Präzisierung – dann ist das sehr ineffizient.

Letztlich ist besteht das Ziel ja darin, Arbeit zu automatisieren, also wegzuschaffen. Der Arbeitsaufwand, jedes Mal neu zu analysieren, ist nicht lohnend. Deswegen haben wir uns für eine automatisierte Lösung entschieden, einfach um effizienter zu sein.

Ein Automation-Tool für Updates zu nutzen ist jetzt kein bahnbrechendes, neues Verfahren. Mittlerweile sind automatisierte Updates in Github fast Standard. Wir haben damit allerdings relativ früh angefangen und in Auftragsprojekte integriert, weil wir das große Potenzial gesehen haben. Mittlerweile gehört der Renovate Bot zu unserem Standard. Um es zusammenzufassen: Eine automatisierte Update-Möglichkeit schafft Sicherheitsvorteile, sie spart Arbeit und Zeit, und somit auch Konzentration.

* Ben Kuhn ist Developer bei Turbine Kreuzberg

(ID:49439527)