Bereitstellungsmethoden
- 4 Minuten
DevOps-Methoden beinhalten häufige Releasezyklen, von denen sowohl die Unternehmen als auch die Benutzer auf vielfältige Weise profitieren. Einzelne Bereitstellungen sind kleiner, daher schneller in der Ausführung und weniger belastend. Doch es ist trotzdem möglich, dass Fehler auftreten. Sie können die Wahrscheinlichkeit für Fehler verringern, indem Sie eine Bereitstellungsmethode wählen, die den Anforderungen Ihres Unternehmens bestmöglich entspricht.
Eine Bereitstellungsmethode haben Sie bereits kennengelernt: die „Epic Deployment“-Methode mit all ihren Auswirkungen und Begleiterscheinungen. Sie haben erfahren, dass diese Methode für moderne Anwendungen nicht geeignet ist. Im DevOps-Bereich wurde eine Reihe von weiteren Bereitstellungsmethoden entwickelt, die je nach Szenario Vor- und Nachteile aufweisen.
Die Rolling-Bereitstellungsmethode
Bei der Rolling-Bereitstellungsmethode wird eine neue Codeversion schrittweise eingeführt. Dabei wird die neue Version nach und nach über einen gewissen Zeitraum in immer mehr Instanzen eingeführt, wodurch die Anzahl der Instanzen mit dem bisherigen Code allmählich abnimmt. Das heißt, dass für eine gewisse Zeit sowohl alte als auch neue Instanzen innerhalb eines Unternehmens ausgeführt werden. So können Sie beispielsweise die Software auf jeweils einem Server, einem virtuellen Computer oder einem Container aktualisieren.
Ein Vorteil dieser Methode ist, dass Sie den neuen Code in der Produktionsumgebung überwachen können, um vor der flächendeckenden Bereitstellung sicherzustellen, dass er die Standards in puncto Leistung, Sicherheit, Zuverlässigkeit usw. erfüllt.
Die Blau/Grün-Bereitstellungsmethode
Bei der Blau/Grün-Bereitstellungsmethode kommen zwei identische Umgebungen zum Einsatz. Bei der einen handelt es sich um eine Testumgebung mit der neuen Softwareversion, bei der anderen um die aktuelle Produktionsumgebung. Wenn die Software ordnungsgemäß funktioniert und die Standards erfüllt, können Sie von der aktuellen Produktionsumgebung zur neuen wechseln, die künftig den gesamten Produktionsdatenverkehr verarbeiten soll.
Dabei stellt die blaue Umgebung die aktuelle Produktionsumgebung dar, die grüne Umgebung ein exaktes Duplikat davon. Die neue Softwareversion wird zunächst in der grünen Umgebung bereitgestellt. Wenn alles reibungslos funktioniert, leiten Sie den Datenverkehr der Anwendung von der blauen zur grünen Umgebung, die nun die neue Produktionsumgebung darstellt.
Ein Vorteil dieser Methode besteht darin, dass der Wechsel sehr schnell ausgeführt werden kann, wodurch Ausfallzeiten vermieden werden. Außerdem können Sie bei Problemen in der grünen Umgebung einfach wieder zurück zur blauen wechseln.
Die Canary-Bereitstellungsmethode
Bei der Canary-Bereitstellungsmethode werden Elemente der Rolling-Bereitstellung mit Elementen der Blau/Grün-Bereitstellung kombiniert. Der Wechsel zur neuen Softwareversion erfolgt nicht überall gleichzeitig, sondern ist zunächst auf einen bestimmten Teil der Produktionsumgebung begrenzt, bevor schließlich der gesamte Datenverkehr zur neuen Version geleitet wird. Die Software wird schrittweise für eine begrenzte Anzahl von Instanzen oder Benutzern bereitgestellt. Sobald Sie sicher sind, dass sie ordnungsgemäß funktioniert, wird ein Rollout für die gesamte Infrastruktur durchgeführt.
Der Name stammt aus einer Zeit, als Kanarienvögel im Bergbau als eine Art „Frühwarnsystem“ zum Schutz vor giftigen Gasen eingesetzt wurden. Bei der Canary-Bereitstellung dienen automatisierte Tests sowie Überwachung und Analyse bei einer begrenzten Anzahl von Instanzen oder Benutzern als Frühwarnsystem für Probleme mit der neuen Version. So wird sichergestellt, dass die Produktionsumgebung nicht beeinträchtigt wird.
Featureflags
Die Methode, bei der Featureflags zum Einsatz kommen, ist für Entwickler eine größere Herausforderung. Bei dieser Methode gibt es nicht zwei getrennte Versionen derselben Software (eine alte und eine neue mit den neuen Funktionen), sondern es gibt eine Softwareversion, die aus der alten Version besteht, der jedoch die Änderungen (neue Funktionen usw.) hinzugefügt wurden. Standardmäßig sind die neuen Änderungen inaktiv und nicht sichtbar, bis das Featureflag für die jeweilige Änderung durch Umschalten aktiviert wird. Ein Flag kann viele verschiedene Formen haben, etwa eine Zeile in einer Konfigurationsdatei, ein Befehlszeilenargument, eine bestimmte Antwort von einem Onlineserver, der von der Software beim Start konsultiert wird usw.
Ein großer Vorteil dieser Methode besteht darin, dass bei Problemen einfach ein Rollback ausgeführt werden kann bzw. die Änderungen einfach nach und nach eingeführt werden. Es muss nicht an alle Server oder Kunden ein neues Release (mit einem nicht unerheblichen Datenumfang) gesendet werden – es genügt, das jeweilige Flag zu aktivieren (Upgrade) bzw. zu deaktivieren (Downgrade).
Bewährte Methoden für die Bereitstellung
Unabhängig von der von Ihnen verwendeten Bereitstellungsmethode haben sich folgende Methoden zur Risikominimierung bei der Einführung neuer Software oder einer neuen Version von vorhandener Software bewährt:
Verwenden Sie zum Erstellen einer Continuous Integration-/Continuous Deployment-Pipeline geeignete Tools, wie z. B. Azure Pipelines.
Integrieren Sie automatisierte Tests.
Benachrichtigen Sie über Kommunikationskanäle die richtigen Stellen über die Testergebnisse, also beispielsweise Notfallteams bei Bereitstellungsfehlern oder Problemen usw.
Überwachung Sie, ob unmittelbar nach der Bereitstellung Probleme auftreten.
Halten Sie einen Rollbackplan bereit, falls die Bereitstellung der neuen Version die Integritätsprüfung nicht besteht oder sie nicht ordnungsgemäß funktioniert.