Best Practices für den gelungenen Software-Rollout Deployment-Methoden im Check

Anbieter zum Thema

New Relic Germany GmbH

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Software wird nicht überall gleich ausgerollt. In manchen Unternehmen werden hunderte kleinere Updates täglich zur Verfügung gestellt, in anderen gibt es lediglich ein Update alle zwei Wochen oder seltener. Damit in beiden Szenarien die Systemnutzung nicht beeinträchtigt wird, spielt die Wahl der Deployment-Methode eine zentrale Rolle.

Bei der Wahl der richtigen Deployment-Methode müssen vorab erst einmal die Grundlagen geklärt werden, denn es gibt nicht die eine perfekte Vorgehensweise. Es kommt immer darauf an, um welche Art von Programm es sich handelt und wie das Team es entwickeln will.

Anwendungen wie z. B. Online-Shops sind für den Geschäftserfolg entscheidend. Jede Minute, in der ein Online-Shop offline ist, kommt das Unternehmen teuer zu stehen. Das Gegenbeispiel ist ein Onlinespiel, bei dem es längere Ausfallzeiten geben kann, um wichtige Updates einzuspielen. Das sorgt vielleicht für ein wenig Ärger in der Community, kostet aber erst einmal kein Geld.

Darüber hinaus gibt es noch eine Reihe anderer Aspekte zu beachten, wie z. B. die Einhaltung von Sicherheitskriterien beim Umgang mit Daten, die einen besonderen Schutz erfordern. Die Entwicklerinnen und Entwickler müssen sich über ihre Prioritäten im Klaren sein, um zu verstehen, wie sie das Deployment angehen.

Verschiedene Deployment-Arten bringen verschiedene Vorteile

Bei einem Basic Deployment werden alle Nodes in der Zielumgebung gleichzeitig aktualisiert, um eine neue Version einzuführen. Diese Strategie ist anfällig für Ausfälle und erschwert es, die Aktualisierung rückgängig zu machen. Das Basic Deployment ist zwar schnell, einfach und kostengünstig, birgt aber das höchste Risiko und ist daher für geschäftskritische Anwendungsdienste ungeeignet.

Ähnlich wie beim Basic Deployment wird beim Multi-Service-Deployment jeder Node in der Zielumgebung aktualisiert. Diese Methode birgt weniger Risiken und ist für Anwendungen mit Versions- oder Serviceabhängigkeiten nützlich. Multi-Service-Deployments sind zwar schnell und kostengünstig, aber sie sind anfällig für Ausfälle und lassen sich nur langsam zurücksetzen. Diese Strategie kann auch das Testen, Überprüfen und Verwalten von Dienstabhängigkeiten erschweren.

Blaues Licht, grünes Licht

Bei einem Blue/Green-Deployment werden zwei Versionen der Anwendung gleichzeitig bereitgestellt. Die aktuelle Version (Blue) und die neue Version (Green) werden in getrennten Umgebungen ausgeführt, wobei immer nur eine Live-Version zur Verfügung steht. Die Blue-Version läuft weiter, während die Green-Version getestet wird. Wenn die neue Version fertig ist, kann der Datenverkehr umgestellt werden, wobei die alte Version entweder außer Betrieb genommen oder für ein späteres Rollback aufbewahrt wird. In einigen Fällen wird die Blue-Umgebung für die nächste Aktualisierung zur Green-Umgebung.

Durch Blue/Green-Implementierungen werden Ausfallzeiten vermieden und sofortige Rollbacks ermöglicht. Die Isolierung von Blue- und Green-Umgebungen schützt beim Live-Deployment vor Fehlern während der Testphase. Diese Deployment-Methode ist zwar weniger risikoreich, aber auch teurer, da der Betriebsaufwand zwei Umgebungen abdecken muss.

Move fast, fail often

Die Start-up-Szene ist dafür bekannt, schnelllebig zu sein. So entwickeln sie auch ihre Software. Frei nach dem Motto: schnell entwickeln, schnell beheben, werden täglich mehrere neue Funktionen zu einer Applikation hinzugefügt. Alles im laufenden Betrieb. Hier hat sich die Feature-Flag-Methode bewährt gemacht. Dabei werden neue Funktionen zunächst an eine ausgewählte Gruppe von Nutzern und Nutzerinnen ausgerollt, um sie zu testen.

Nach und nach erhalten dann immer mehr User den Zugriff auf die neuen Funktionen. Auf diese Weise können Fehler schnell gefunden werden und betreffen im schlimmsten Fall nur einen kleinen Teil der gesamten Nutzerschaft. Nach Fehlerbehebung kann schließlich der Rollout Stück für Stück weiter erfolgen.

Ähnlich funktioniert auch die Canary Deployment Methode. Der Unterschied zwischen beiden ist, dass bei einem Canary Deployment, eine kleine Gruppe an User ausgewählt wird, die die neuen Funktionen erhalten. Bei der Feature-Flag-Methode erhalten theoretisch alle Benutzer die neuen Funktionen, aber sie werden im Code versteckt und auch hier kann nur ein kleiner Teil Nutzer:innen die Funktionen tatsächlich testen.

Mehr als nur die Deployment-Methode

Die Deployment-Methode allein macht die Arbeit jedoch nicht einfacher. Sehr oft passiert es Entwicklungsteams, dass sie nach einem Feature Drop oder einem Update plötzlich eine Nachtschicht einlegen müssen. Trotz vorheriger Tests tauchen manche Fehler erst auf, wenn die Benutzer das Programm intensiv nutzen. Und dann muss das ganze Team auf Fehlersuche gehen.

Daher ist es unabhängig von der Deployment-Methode sehr nützlich, mit Beschäftigungsmarkierungen zu arbeiten. Auf diese Weise können Arbeitsversionen markiert werden. Treten nun in einer neueren Version Fehler auf, können die beiden schnell und einfach verglichen werden. Mithilfe dieser Funktion werden auch alle Fehler - und seien sie noch so klein - schnell beseitigt. Die Nachtschicht wird abgebrochen, das Programm läuft wieder schnell und das Team ist zufrieden.

Einsatzprotokolle sind ein weiterer Baustein für erfolgreichere Einsätze. Bei der täglichen Arbeit scheint es oft so, als ob eine gute Pflege der Protokolle vor allem Zeit kostet, aber beim Deployment zahlt sich dieser Aufwand mehr als aus. Wichtig ist dabei, dass die Protokolle miteinander verbunden sind. Wenn zum Beispiel ein Fehler im Frontend sichtbar wird, ist sofort ersichtlich, wo die Quelle im Backend oder Datalog liegt. Auf diese Weise wird das Deployment einfacher und vor allem weniger fehleranfällig - bevor eine neue Version freigegeben wird.

Je besser die Datenpipeline gepflegt ist, desto schneller können die Entwickler reagieren. Und diese Sicherheit bedeutet auch, dass das Deployment von vornherein sicherer durchgeführt wird, was letztlich zu weniger Fehlern führt.

Die genannten Methoden sind nur ein Beispiel der möglichen Deployment-Strategien und sind immer für den vorliegenden Anwendungsfall abzuwägen. Gut geführte Deployment-Protokolle und Beschäftigungsmarkierungen erleichtern den Entwicklungsteams die Arbeit während des Deployment erheblich, unabhängig von der Deployment-Methode. Auftretende Fehler lassen sich so schnell erkennen und beheben, damit alles wieder zuverlässig läuft.

* Aidan Cuffe ist Senior Product Manager bei New Relic. In seinen bisher 8 Jahren im Unternehmen war er bereits in verschiedenen Bereichen tätig, von Technical Support, Technical Sales, Customer Success Enablement, Solution Architect bis hin zu Product Management.

(ID:48749951)