Dmitry Nikolaev - stock.adobe.co
Die richtige Deployment-Methode für Software wählen
Im besten Fall bemerken Anwender keine Fehler nach Updates. Damit dieses ideale Szenario eintritt, spielt die Wahl der richtigen Deployment-Methode eine große Rolle.
Bevor es an die Wahl der Deployment-Methode geht, ist der Blick auf die Programmumgebung wichtig. Die großen Cloud-Anbieter haben in den letzten Jahren ein Umfeld geschaffen, in dem mit einzelnen Produkten alles vereinfacht wird – auch das Deployment. Hier ist alles perfekt aufeinander abgestimmt, bietet Entwicklern aber auch wenig Freiräume.
Mit Unternehmen wie Heroku oder Render, die Deployment als Software as a Service (SaaS) anbieten, holen sich Teams etwas Freiheit zurück, ohne auf den Service großer Anbieter zu verzichten. Denn auch mit SaaS-Anbietern läuft das Deployment weiterhin schnell, einfach und ohne, dass ein großes Entwicklerteam notwendig ist. Einmal in die Infrastruktur eingebunden und an die eigenen Prozesse angepasst, kann entsprechend gearbeitet werden. Dadurch erhalten Entwickler viel Freiraum, da sie wenig selbst aufsetzen und konfigurieren müssen.
Vom SaaS zum eigenen DevOps-Team
Doch wie so oft hat die Medaille zwei Seiten: Gegenüber dem einfachen und schnellen Deployment stehen ab einer gewissen Projektgröße entsprechend hohe Kosten. Zum schnellen Start kleinerer IT-Anwendungen ist es sinnvoll, auf bestehende Lösungen zu setzen – und es ist sogar in der Regel günstiger.
Die Alternative ist, ein DevOps-Team aufzubauen. Daher nutzen gerade Start-ups in der Startphase Dienste von SaaS-Anbietern. Doch je komplexer die Anwendung, die Features und damit das Deployment wird, desto teurer werden auch diese Angebote. Bei steigenden Nutzerzahlen wird das Deployment ebenfalls komplexer – und damit teurer.
Ab einem bestimmten Punkt bleibt Entwicklern also oft nur der Wechsel von SaaS-Anbietern entweder hin zu einem der großen Cloud-Anbieter oder der Aufbau eines eigenen DevOps-Teams. Wenn das Deployment selbst umgesetzt wird, ist der Zeitpunkt gekommen, die Deployment-Methode noch einmal genau unter die Lupe zu nehmen. Was mit einem SaaS-Anbieter funktioniert hat, muss nicht gleichzeitig im eigenen Team genauso gut und reibungslos ablaufen.
Nicht jede Deployment-Methode funktioniert für jede Anwendung
Bei der Wahl der Deployment-Methode sollte sich daher jedes Team einige Fragen stellen, um die richtige Methode zu finden. Dabei ist es egal, ob die Lösung mit einem eigenen Team oder einer technischen Lösung im Hintergrund umgesetzt werden soll. Denn es gibt nicht die eine perfekte Deployment-Methode.
Es kommt immer darauf an, von welcher Art von Programm wir sprechen und wie das Team dieses weiterentwickeln möchte. Es gibt Anwendungen, wie zum Beispiel Online-Shops, die kritisch für den Geschäftserfolg sind. Jede Minute, in der ein Online-Shop nicht erreichbar ist, kostet Geld. Das Gegenbeispiel ist ein Online-Game, bei dem es oft längere Downtimes gibt, um größere Updates einzuspielen. Zudem sind einige weitere Punkte zu beachten, beispielsweise das Erfüllen von Sicherheitskriterien beim Umgang mit besonders schützenswerten Daten. Entwickler müssen sich über die Prioritäten im Klaren sein, um zu verstehen, wie sie an das Deployment herangehen.
Einige Entwicklerteams agieren nach dem Motto: Schnell entwickeln, schnell fixen. Hier werden teilweise mehrmals täglich neue Features in eine neue App eingebaut. Es sollen also möglichst schnell neue Funktionen hinzugefügt werden, und dies im laufenden Betrieb. Als passende Deployment-Methode wählen Teams dafür gerne die Feature-Flag-Methode aus.
Die neuen Versionen und Features werden zunächst an eine ausgewählte Nutzergruppe ausgespielt, um sie zu testen. Nach und nach erhalten dann immer mehr Nutzer die neuen Funktionen. Auf diese Weise können anhand der kleinen Gruppe schnell mögliche Fehler gefunden und vor allem behoben werden, ehe die neue Version für alle Nutzer Stück für Stück ausgerollt wird. Für diese Arbeits- und Herangehensweise passt die Feature-Flag-Methode daher gut.
Fehler schnell finden und beheben
Doch die Deployment-Methode allein macht die Arbeit noch nicht einfacher. Häufig passiert es Entwicklerteams, dass sie nach einem Feature-Drop oder einem Update plötzlich eine Nachtschicht einlegen müssen. Trotz voriger Tests kommen einige Fehler erst auf, wenn die Nutzer das Programm intensiv nutzen. Und dann muss das ganze Team auf Fehlersuche gehen.
Daher ist es unabhängig von der Deployment-Methode sinnvoll, mit Employment-Markern zu arbeiten. Auf diese Weise können funktionierende Versionen markiert werden. Sollten Fehler bei einer neueren Version auftreten, kann man beide schnell und einfach vergleichen. Mit dieser Funktion sind alle Fehler schnell beseitigt – seien sie noch so klein.
Logs sind ein weiterer Baustein für erfolgreichere Deployments. Während der täglichen Arbeit erscheint es oft, als würde eine gute Pflege der Logs vor allem Zeit in Anspruch nehmen. Doch beim Deployment macht sich dieser Aufwand bezahlt. Wichtig ist, dass die Logs miteinander vernetzt sind. Wenn nun zum Beispiel ein Fehler im Frontend sichtbar wird, ist sofort ersichtlich, wo im Backend oder Datalog die Quelle liegt. Auf diese Weise wird das Deployment einfacher und weniger fehleranfällig – bevor eine neue Version veröffentlicht wird.
Je besser die Datenpipeline gepflegt ist, desto schneller können Entwickler reagieren. Und diese Sicherheit führt auch dazu, dass das Deployment von vornherein selbstbewusster durchgeführt wird, was letztlich zu weniger Fehlern führt.
„Je besser die Datenpipeline gepflegt ist, desto schneller können Entwickler reagieren. Und diese Sicherheit führt auch dazu, dass das Deployment von vornherein selbstbewusster durchgeführt wird, was letztlich zu weniger Fehlern führt.“
Aidan Cuffe, New Relic
Die Deployment-Methode muss also gut gewählt werden, damit sie auch zur Strategie passt und die Entwickler das Programm erfolgreich voranbringen. Gut gepflegte Deployment Logs und Employment Marker machen das Leben von Entwicklerteams beim Deployment einfacher, völlig unabhängig von der Methode. So können auftretende Fehler schnell erkannt und behoben werden, damit alles wieder zuverlässig läuft.
Über den Autor:
Aidan Cuffe ist Senior Product Manager bei New Relic. Er ist auf Observability spezialisiert und hat bereits mehr als acht Jahre Erfahrung bei New Relic in verschiedenen Bereichen der Kundenerfahrung, vom technischen Support, technischen Vertrieb, Customer Success Enablement, Solution Architect bis hin zum Produktmanagement.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
