Bereitstellungsstrategien

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.

Sie kennen bereits den Ansatz der „epischen Bereitstellung“, der oft auch als „Big Bang“-Strategie bezeichnet wird. 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. Die neue Version wird über einen bestimmten Zeitraum schrittweise eingeführt, wobei die Instanzen des neuen Codes schrittweise erhöht und die Instanzen des alten Codes verringert werden. Daher sind alte und neue Instanzen während des Rollouts über das Bereitstellungsziel hinweg vorhanden. Beispielsweise können Sie die Software auf einem Server, virtuellen Computer oder Container gleichzeitig 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-Bereitstellungsstrategie

Die blaugrüne Bereitstellungsstrategie verwendet zwei separate Umgebungen, die so ähnlich wie möglich gehalten werden und beide in der Lage sind, den Produktionsdatenverkehr zu bedienen. Eine Umgebung behandelt die aktuelle Produktionslast, während die andere die neue Version der Software hostt, damit Sie sie überprüfen können, bevor Sie den Datenverkehr verschieben. Wenn Sie zufrieden sind, dass die neue Version fehlerfrei ist, können Sie den Datenverkehr auf einmal wechseln oder den Anteil des Datenverkehrs in die neue Umgebung schrittweise erhöhen, während Sie die Ergebnisse überwachen.

Die blaue Umgebung ist die, die derzeit den Produktionsverkehr bedient. Die grüne Umgebung ist ihr paralleles Gegenstück. Sie stellen zuerst die neue Version der Software in der Green-Umgebung bereit, validieren sie und leiten dann den Produktionsdatenverkehr von der Blue-Umgebung zur Green-Umgebung weiter. Nach der Umstellung können die Rollen wechseln: grün wird zur Liveumgebung, und blau kann für die nächste Freigabe vorbereitet werden.

Ein Vorteil dieser Strategie ist, dass Sie schnell wechseln können, oft mit wenig oder ohne Ausfallzeiten. Es ist auch relativ einfach, den Datenverkehr zurück zur vorherigen Umgebung zu leiten, wenn ein Problem auftritt, nachdem die neue Umgebung live ist.

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.

Feature-Flags

Die Feature-Flag-Idee ist eine weitere Strategie, die von den Entwicklern etwas mehr Raffinesse erfordert. Anstatt zwei separate Versionen derselben Software (ein altes und ein neues mit neuen Features) zu haben, versenden Sie eine einzelne Version, die das alte Verhalten sowie die neuen Änderungen enthält. Die neuen Änderungen sind standardmäßig deaktiviert und werden erst angezeigt, wenn das entsprechende "Feature-Flag" aktiviert ist. Ein Flag kann viele Formen annehmen, einschließlich einer Zeile in einer Konfigurationsdatei, einem Befehlszeilenargument oder einem Wert, der von einem Remotekonfigurationsdienst abgerufen und zur Laufzeit ausgewertet wird.

Ein entscheidender Vorteil dieses Ansatzes ist die einfache Möglichkeit des Zurücksetzens, wenn ein Problem auftritt, und dass Änderungen schrittweise eingeführt werden können. In vielen Fällen müssen Sie keine neue Version versenden, um das Feature verfügbar zu machen oder auszublenden. Sie können einfach die entsprechende Kennzeichnung deaktivieren oder aktivieren und die aktive Anwendung auf die neue Einstellung reagieren lassen.

Auf Azure stellt die featureverwaltungfunktion von Azure App Configuration einen verwalteten Feature-Flag-Speicher bereit, aus dem Ihre Anwendungen zur Laufzeit lesen können, mit SDK-Unterstützung für .NET, Java, Python, JavaScript und Go.

Ringbasierte Bereitstellungen

Eine ringbasierte Bereitstellung ist eine strukturierte Form des progressiven Rollouts, die weit in Microsoft und Azure verwendet wird. Neuer Code wird für eine Abfolge von "Ringen" freigegeben. Beispielsweise ein interner oder Dogfood-Ring, ein Early Adopter-Ring, ein breiter Bereitstellungsring und schließlich ein allgemeiner Verfügbarkeitsring. Jeder Ring ist größer als der vorherige, und die Bereitstellung schreitet nur zum nächsten Ring fort, nachdem die Gesundheitssignale des aktuellen Rings definierte Kriterien erfüllen. Ringbasierte Bereitstellungen kombinieren die graduelle Einführung von Canary-Bereitstellungen mit expliziten, benannten Zielgruppen und Genehmigungsschranken zwischen Ringen.

Progressive Lieferung

Die oben genannten Strategien (Canary, Ringbasierte und Feature-Flags) werden häufig unter dem Dachbegriff progressive Bereitstellung zusammengefasst. Die vereinende Idee besteht darin, dass eine Version einer kontrollierten, wachsenden Zielgruppe bereitgestellt wird, die mit Gesundheits- und Geschäftsmetriken instrumentiert ist, und entweder automatisch basierend auf diesen Signalen weitergeführt oder zurückgerollt wird. Die progressive Zustellung ist zunehmend das Standardmodell für hochzuverlässige Clouddienste, da sie den Strahlradius jeder einzelnen Änderung einschränkt.

Bewährte Methoden für die Bereitstellung

Unabhängig davon, welche Bereitstellungsstrategie Sie verwenden, helfen Ihnen einige bewährte Methoden, Risiken beim Rollout neuer Software oder einer neuen Version vorhandener Software zu minimieren:

• Verwenden Sie geeignete Tools wie Azure Pipelines oder GitHub Actions, um eine kontinuierliche Integrations- und Bereitstellungspipeline zu erstellen.

• Integrieren Sie automatisierte Tests.

• Verwenden Sie Kommunikationskanäle, um die richtigen Parteien über Testergebnisse zu informieren. Benachrichtigen Sie Teams beispielsweise, wenn Bereitstellungen fehlschlagen oder Probleme auftreten.

• Überwachen Sie unmittelbar nach der Bereitstellung, ob Probleme auftreten.

• Planen Sie einen Rollback, wenn eine neue Version die Integritätsprüfungen nicht besteht oder nicht ordnungsgemäß funktioniert.