Strategien für Bereitstellung und Tests von Anwendungen

Last reviewed 2023-07-20 UTC

Dieses Dokument bietet eine Übersicht über häufig verwendete Muster für die Anwendungsbereitstellung und Anwendungstests. Es wird beschrieben, wie die Muster funktionieren, welche Vorteile sie bieten und welche Aspekte Sie bei der Implementierung beachten sollten.

Beispiel: Sie möchten eine laufende Anwendung auf eine neue Version aktualisieren. Für einen nahtlosen Rollout sollten Sie in der Regel folgende Kriterien berücksichtigen:

  • Wie sich Anwendungsausfallzeiten minimieren oder vermeiden lassen.
  • Wie sich Vorfälle mit minimalen Auswirkungen für Nutzer bewältigen und beheben lassen.
  • Wie sich mit fehlgeschlagenen Bereitstellungen auf zuverlässige, effektive Weise umgehen lässt.
  • Wie Fehler durch Personen oder Prozesse reduziert werden können, um vorhersehbare, wiederholbare Bereitstellungen zu erreichen.

Welches Bereitstellungsmuster Sie wählen, hängt weitgehend von Ihren Unternehmenszielen ab. Vielleicht möchten Sie z. B. Änderungen ohne Ausfallzeit übernehmen oder erst einmal nur für eine bestimmte Umgebung oder Nutzergruppe, bevor Sie ein Feature allgemein verfügbar machen. Jede in diesem Dokument beschriebene Methode berücksichtigt bestimmte Ziele, die Sie erreichen müssen, bevor eine Bereitstellung als erfolgreich gilt.

Dieses Dokument richtet sich an Systemadministratoren und DevOps-Entwickler, die daran arbeiten, Release- und Bereitstellungsstrategien für verschiedene Anwendungen, Systeme und Frameworks zu definieren und umzusetzen.

Bereitstellungsstrategien

Wenn Sie einen Dienst bereitstellen, ist er nicht immer sofort für Nutzer verfügbar. Manchmal sind Änderungen an der Anwendung erst nach dem Release des Dienstes für Nutzer sichtbar. Wenn jedoch ein direkter Release eines Dienstes erfolgt, erfolgen Bereitstellung und Release gleichzeitig. In diesem Fall beginnt die neue Version nach ihrer Bereitstellung damit, Produktionstraffic zu verarbeiten. Alternativ gibt es auch Bereitstellungsstrategien, bei denen mehrere Dienstversionen parallel bereitgestellt werden. Mit diesen Bereitstellungsmustern können Sie steuern und verwalten, welche Version eine eingehende Anfrage erhält. Unter Kubernetes und die Herausforderungen der kontinuierlichen Softwarebereitstellung finden Sie weitere Informationen zu Bereitstellungen, Releases und ähnlichen Konzepten.

Die in diesem Abschnitt beschriebenen Bereitstellungsmuster bieten Ihnen Flexibilität beim Automatisieren der Freigabe neuer Software. Welcher Ansatz für Sie am besten geeignet ist, hängt von Ihren Zielen ab.

Bereitstellungsmuster mit Neuerstellung

Bei einer neu erstellten Bereitstellung skalieren Sie die vorhandene Anwendungsversion vollständig herunter, bevor Sie die neue Anwendungsversion hochskalieren.

Das folgende Diagramm zeigt, wie eine neu erstellte Bereitstellung bei einer Anwendung funktioniert.

Der Ablauf einer neu erstellten Bereitstellung.

Version 1 steht für die derzeitige Anwendungsversion und Version 2 für die neue Anwendungsversion. Wenn Sie die derzeitige Anwendungsversion aktualisieren, skalieren Sie zuerst die vorhandenen Replikate von Version 1 auf null und stellen dann gleichzeitig Replikate mit der neuen Version bereit.

Hauptvorteile

Der Vorteil der Neuerstellung liegt in ihrer Einfachheit. Sie müssen nicht mehr als eine Anwendungsversion gleichzeitig verwalten. So vermeiden Sie Probleme mit der Abwärtskompatibilität Ihrer Daten und Anwendungen.

Hinweise

Bei der Methode der Neuerstellung treten während des Aktualisierungsvorgangs Ausfallzeiten auf. Ausfallzeiten sind kein Problem für Anwendungen, die mit Wartungsfenstern oder Unterbrechungen umgehen können. Wenn Sie jedoch geschäftskritische Anwendungen mit hohen Anforderungen an Service Level Agreements (SLAs) und Verfügbarkeit haben, könnte die Wahl einer anderen Bereitstellungsstrategie besser für Sie sein.

Rolling Update-Bereitstellungsmuster

Bei einer Rolling Update-Bereitstellung aktualisieren Sie nur eine Teilmenge der ausgeführten Anwendungsinstanzen, statt alle gleichzeitig zu aktualisieren, wie im folgenden Diagramm gezeigt.

Der Ablauf einer Rolling Update-Bereitstellung.

Bei diesem Ansatz wird die Anzahl der Instanzen, die Sie gleichzeitig aktualisieren, als Fenstergröße bezeichnet. Im vorherigen Diagramm hat das Rolling Update eine Fenstergröße von 1. Jeweils eine Anwendungsinstanz wird aktualisiert. Wenn Sie einen größeren Cluster haben, können Sie die Fenstergröße erhöhen.

Rolling Updates bieten Ihnen bei der Aktualisierung Ihrer Anwendung Flexibilität:

  • Sie können die Anwendungsinstanzen mit der neuen Version hochskalieren, bevor Sie die alte Version herunterskalieren (dieser Vorgang wird als Surge-Upgrade bezeichnet).
  • Sie können die maximale Anzahl von Anwendungsinstanzen angeben, die nicht verfügbar sind, während neue Instanzen parallel hochskaliert werden.

Hauptvorteile

  • Keine Ausfallzeiten. Anhand der Fenstergröße aktualisieren Sie Bereitstellungsziele schrittweise, z. B. eins zu eins oder zwei zu zwei. Sie leiten den Traffic erst dann an die aktualisierten Bereitstellungsziele weiter, wenn die neue Version der Anwendung bereit ist, Traffic zu verarbeiten.
  • Verringertes Bereitstellungsrisiko. Wenn Sie eine Aktualisierung schrittweise ausführen, wirkt sich eine mögliche Instabilität in der neuen Version nur auf einen Teil der Nutzer aus.

Hinweise

  • Langsames Rollback. Wenn der neue Rollout instabil ist, können Sie die neuen Replikate beenden und die alte Version noch einmal bereitstellen. Genau wie ein Rollout ist ein Rollback jedoch ein gradueller, schrittweiser Prozess.
  • Abwärtskompatibilität. Da neuer Code und alter Code nebeneinander existieren, werden Nutzer möglicherweise beliebig zu einer der beiden Versionen weitergeleitet. Sorgen Sie deshalb dafür, dass die neue Bereitstellung abwärtskompatibel ist, sprich die neue Anwendungsversion Daten lesen und verarbeiten kann, die in der alten Version gespeichert sind. Dazu können Daten gehören, die auf Laufwerken, in einer Datenbank oder als Teil der Browsersitzung eines Nutzers gespeichert sind.
  • Sitzungstreue. Wenn für die Anwendung Sitzungspersistenz erforderlich ist, empfehlen wir, dass der Load-Balancer die Sitzungstreue und den Verbindungsausgleich unterstützt. Wir empfehlen außerdem, nach Möglichkeit eine Sitzungsfreigabe zu veranlassen (durch die Sitzungsreplikation oder eine Sitzungsverwaltung mithilfe eines Datenspeichers), damit die Sitzungen von den zugrunde liegenden Ressourcen entkoppelt werden können.

Blau/Grün-Bereitstellungsmuster

Bei einer Blau/Grün-Bereitstellung (auch als Rot/Schwarz-Bereitstellung bezeichnet) führen Sie zwei identische Bereitstellungen Ihrer Anwendung aus, wie im folgenden Diagramm gezeigt.

Der Ablauf einer Blau/Grün-Bereitstellung.

Im Diagramm steht blau für die derzeitige Anwendungsversion und grün für die neue Anwendungsversion. Es ist jeweils nur eine Version live. Der Traffic wird an die blaue Bereitstellung weitergeleitet, während die grüne Bereitstellung erstellt und getestet wird. Wenn Sie die Tests abgeschlossen haben, leiten Sie den Traffic an die neue Version weiter.

Nachdem die Bereitstellung erfolgreich war, können Sie entweder die blaue Bereitstellung für ein mögliches Rollback beibehalten oder außer Betrieb nehmen. Alternativ können Sie eine neuere Version der Anwendung auf diesen Instanzen bereitstellen. In diesem Fall dient die derzeitige (blaue) Umgebung als Staging-Bereich für den nächsten Release.

Hauptvorteile

  • Keine Ausfallzeiten. Mit einer Blau/Grün-Bereitstellung ist eine schnelle Umstellung ohne Ausfallzeiten möglich.
  • Sofortiges Rollback. Während des Bereitstellungsprozesses können Sie jederzeit ein Rollback ausführen. Dazu passen Sie den Load-Balancer so an, dass der Traffic zurück zur blauen Umgebung geleitet wird. Die Auswirkungen der Ausfallzeiten beschränken sich auf die Dauer, die nötig ist, um den Traffic in die blaue Umgebung zu verschieben, nachdem Sie ein Problem erkannt haben.
  • Trennung der Umgebungen. Durch die Blau/Grün-Bereitstellung ist sichergestellt, dass das Starten einer parallelen grünen Umgebung keine Auswirkungen auf Ressourcen hat, die die blaue Umgebung unterstützen. Diese Trennung verringert das Bereitstellungsrisiko.

Hinweise

  • Kosten und operativer Aufwand. Die Anwendung des Blau/Grün-Bereitstellungsmusters kann zu einem höheren operativen Aufwand und höheren Kosten führen, da Sie doppelte Umgebungen mit identischer Infrastruktur pflegen müssen.
  • Abwärtskompatibilität. Blaue und grüne Bereitstellungen können sich Datenpunkte und Datenspeicher teilen. Wir empfehlen Ihnen, zu prüfen, ob beide Versionen der Anwendung das Schema des Datenspeichers und das Format der Datensätze verwenden können. Diese Abwärtskompatibilität ist erforderlich, wenn Sie bei einem Rollback nahtlos zwischen den beiden Versionen wechseln möchten.
  • Umstellung. Wenn Sie die derzeitige Version außer Betrieb nehmen möchten, empfehlen wir Ihnen, einen angemessenen Verbindungsausgleich für vorhandene Transaktionen und Sitzungen zu ermöglichen. Mit diesem Schritt können von der derzeitigen Bereitstellung verarbeitete Anfragen ordnungsgemäß abgeschlossen oder beendet werden.

Teststrategien

Die in diesem Abschnitt besprochenen Testmuster werden üblicherweise verwendet, um die Zuverlässigkeit und Stabilität eines Dienstes über einen angemessenen Zeitraum und anhand eines realistischen Maßes an Gleichzeitigkeit und Last zu prüfen.

Canary-Testmuster

Beim Canary-Test führen Sie eine Änderung teilweise ein und bewerten dann deren Leistung anhand einer Referenzbereitstellung, wie das folgende Diagramm zeigt.

Die Konfiguration für einen Canary-Test.

Bei diesem Testmuster stellen Sie eine neue Version Ihrer Anwendung zusammen mit der Produktionsversion bereit. Anschließend teilen Sie den Traffic auf, leiten einen Teil des Traffics von der Produktionsversion an die Canary-Version weiter und bewerten die Canary-Leistung.

Sie wählen die wichtigsten Messwerte für die Bewertung aus, wenn Sie die Canary-Version konfigurieren. Wir empfehlen, die Canary-Version mit einer gleichwertigen Referenzversion und nicht mit der Live-Produktionsumgebung zu vergleichen.

Zum Reduzieren der Faktoren, die sich auf Ihre Analyse auswirken können (z. B. Caching, langlebige Verbindungen und Hash-Objekte), sollten Sie für die Referenzversion Ihrer Anwendung die folgenden Schritte ausführen:

  • Achten Sie darauf, dass die Referenzversion und die Produktionsversion Ihrer Anwendung identisch sind.
  • Stellen Sie die Referenzversion zur gleichen Zeit bereit, zu der Sie die Canary-Version bereitstellen.
  • Achten Sie darauf, dass die Referenzbereitstellung (z. B. bei der Anzahl der Anwendungsinstanzen und Autoscaling-Richtlinien) mit der Canary-Bereitstellung übereinstimmt.
  • Verwenden Sie die Referenzversion so, dass sie denselben Traffic wie die Canary-Version bereitstellt.

Bei Canary-Tests kann die teilweise Einführung anhand verschiedener Partitionierungsstrategien ablaufen. Wenn die Anwendung beispielsweise geografisch verteilte Nutzer hat, können Sie die neue Version zuerst in einer Region oder an einem bestimmten Standort einführen. Weitere Informationen finden Sie unter Canary-Analyse in GKE mit Spinnaker automatisieren.

Hauptvorteile

  • Möglichkeit zum Testen des Live-Produktionstraffics. Anstatt eine Anwendung mithilfe simulierten Traffics in einer Staging-Umgebung zu testen, können Sie Canary-Tests für den Live-Produktionstraffic ausführen. Bei Canary-Rollouts müssen Sie entscheiden, in welchem Umfang Sie die neue Anwendung bei jedem Schritt freigeben und wann Sie den nächsten Schritt in einem Release auslösen. Der Canary-Test benötigt genügend Traffic, damit Probleme über Monitoring zweifelsfrei erkannt werden können.
  • Schnelles Rollback. Sie können schnell ein Rollback ausführen, indem Sie den Nutzertraffic an die ältere Version der Anwendung weiterleiten.
  • Keine Ausfallzeiten. Mit Canary-Releases können Sie den Live-Produktionstraffic ohne Ausfallzeit an verschiedene Versionen der Anwendung weiterleiten.

Hinweise

  • Langsame Einführung. Für jeden schrittweisen Release ist ein Monitoring über einen angemessenen Zeitraum erforderlich, wodurch sich der Release insgesamt verzögern kann. Canary-Tests können oft mehrere Stunden dauern.
  • Beobachtbarkeit. Eine Voraussetzung für die Umsetzung von Canary-Tests ist die Möglichkeit, Ihre Infrastruktur und Ihr Anwendungspaket wirksam zu beobachten und zu überwachen. Die Einbindung eines robusten Monitorings kann einen erheblichen Aufwand erfordern.
  • Abwärtskompatibilität und Sitzungstreue. Wie bei Rolling Updates können auch bei Canary-Tests Risiken für die Abwärtskompatibilität und Sitzungspersistenz auftreten, da während der Bereitstellung der Canary-Version in der Umgebung mehrere Anwendungsversionen ausgeführt werden.

A/B-Testmuster

Bei A/B-Tests testen Sie eine Hypothese mithilfe von Variantenimplementierungen. A/B-Tests werden verwendet, um Unternehmensentscheidungen (nicht nur Vorhersagen) anhand von aus Daten abgeleiteten Ergebnissen zu treffen.

Bei einem A/B-Test leiten Sie einen Teil der Nutzer anhand von Weiterleitungsregeln zu neuen Funktionen weiter, wie das folgende Diagramm zeigt.

Die Konfiguration für einen A/B-Test.

Routingregeln umfassen häufig Faktoren wie die Browserversion, den User-Agent, die Standortbestimmung und das Betriebssystem. Nachdem Sie die Messwerte der Versionen verglichen haben, aktualisieren Sie die Produktionsumgebung mit der Version, die bessere Ergebnisse geliefert hat.

Hauptvorteile

A/B-Tests sollten am besten für die Messung der Wirksamkeit von Funktionen in einer Anwendung verwendet werden. Bei den Anwendungsfällen für die zuvor beschriebenen Bereitstellungsmuster stehen die sichere Einführung neuer Software und vorhersehbare Rollbacks im Mittelpunkt. Bei A/B-Tests steuern Sie Ihre Zielgruppe mit Blick auf die neuen Features und überwachen statistisch signifikante Unterschiede im Nutzerverhalten.

Hinweise

  • Komplexe Einrichtung. A/B-Tests benötigen eine repräsentative Stichprobe, mit der sich nachweisen lässt, dass eine Version besser ist als die andere. Sie müssen die Stichprobengröße vorab berechnen (z. B. mit einem Rechner für A/B-Stichprobengrößen) und die Tests für einen angemessenen Zeitraum durchführen, um eine statistische Signifikanz von mindestens 95 % zu erreichen.
  • Gültigkeit der Ergebnisse. Mehrere Faktoren können die Testergebnisse verfälschen, darunter falsch positive Ergebnisse, verzerrte Stichproben oder externe Faktoren (wie Saisonabhängigkeit oder Marketingaktionen).
  • Beobachtbarkeit. Wenn Sie mehrere A/B-Tests für sich überschneidenden Traffic durchführen, können Monitoring und Fehlerbehebung schwierig sein. Wenn Sie beispielsweise Produktseite A mit Produktseite B oder Zahlungsseite C mit Zahlungsseite D vergleichen, ist verteiltes Tracing wichtig, um Messwerte wie die Trafficaufteilung zwischen den Versionen zu ermitteln.

Shadow-Testmuster

Bei sequenziellen Testverfahren wie Canary-Tests kommen Kunden zu Beginn der Testphase möglicherweise mit einer schlechteren Anwendungsversion in Berührung. Sie können dieses Risiko mit Offlineverfahren wie Simulationen verwalten. Allerdings werden durch Offlineverfahren nicht die Verbesserungen der Anwendung validiert, da es keine Nutzerinteraktion mit den neuen Versionen gibt.

Bei Shadow-Tests stellen Sie eine neue Version bereit und führen sie zusammen mit der derzeitigen Version aus, jedoch so, dass die neue Version für die Nutzer nicht sichtbar ist, wie das folgende Diagramm zeigt.

Die Konfiguration für einen Shadow-Test.

Eine eingehende Anfrage wird gespiegelt und in einer Testumgebung wiedergegeben. Dieser Vorgang kann entweder in Echtzeit oder auch asynchron erfolgen, nachdem eine Kopie des zuvor erfassten Produktionstraffics für den neu bereitgestellten Dienst wiedergegeben wurde.

Sie müssen darauf achten, dass die Shadow-Tests keine Nebenwirkungen auslösen, die die vorhandene Produktionsumgebung oder den Nutzerstatus verändern können.

Hauptvorteile

  • Keine Auswirkungen auf die Produktion. Da der Traffic dupliziert wird, haben mögliche Fehler in Diensten, die Shadow-Daten verarbeiten, keine Auswirkungen auf die Produktion.
  • Neue Backend-Features mithilfe der Produktionslast testen. Wenn Sie dafür Tools wie Diffy verwenden, können Sie mithilfe von Traffic-Shadowing das Verhalten Ihres Dienstes gegenüber Live-Produktionstraffic messen. Somit können Sie Anwendungsversionen auf Unterschiede bei Fehlern, Ausnahmen, Leistung und Ergebnisgleichheit testen.
  • Verringertes Bereitstellungsrisiko. Traffic-Shadowing wird in der Regel mit anderen Ansätzen wie Canary-Tests kombiniert. Nach dem Test eines neuen Features mithilfe von Traffic-Shadowing testen Sie anschließend die Nutzerfreundlichkeit, indem Sie das Feature nach und nach für immer mehr Nutzer freigeben. Es erfolgt kein vollständiger Rollout, bis die Anwendung die Anforderungen an Stabilität und Leistung erfüllt.

Hinweise

  • Nebeneffekte. Beim Traffic-Shadowing müssen Sie vorsichtig im Umgang mit Diensten sein, deren Status mutiert oder die mit Drittanbieterdiensten interagieren. Wenn Sie beispielsweise einen Shadow-Test für einen Zahlungsdienst einer Einkaufswagen-Plattform durchführen möchten, könnte es passieren, dass die Kunden zweimal für ihre Bestellung bezahlen. Um Shadow-Tests zu vermeiden, die zu unerwünschten Mutationen oder anderen riskanten Interaktionen führen können, empfehlen wir Ihnen, anstelle von Drittanbietersystemen oder -datenspeichern entweder Stubs oder Virtualisierungstools wie Hoverfly zu verwenden.
  • Kosten und operativer Aufwand. Das Einrichten von Shadow-Tests ist relativ komplex. Wie bei Blau/Grün-Bereitstellungen sind bei Shadow-Bereitstellungen außerdem Auswirkungen auf die Kosten und den operativen Aufwand zu erwarten, da für den Aufbau zwei Umgebungen parallel ausgeführt und gepflegt werden müssen.

Auswahl der geeigneten Strategie

Sie können Ihre Anwendung auf verschiedene Arten bereitstellen und freigeben. Jede Methode hat Vor- und Nachteile. Die beste Wahl hängt von den Anforderungen und Einschränkungen Ihres Unternehmens ab. Achten Sie dabei auf Folgendes:

  • Was sind Ihre wichtigsten Überlegungen? Sind beispielsweise Ausfallzeiten akzeptabel? Sind Sie durch Kosten eingeschränkt? Verfügt Ihr Team über die erforderlichen Fähigkeiten, um komplexe Konfigurationen für Rollouts und Rollbacks vorzunehmen?
  • Haben Sie strenge Testkontrollen oder möchten Sie die neuen Releases anhand des Produktionstraffics testen, um die Stabilität des Releases sicherzustellen und negative Auswirkungen zu begrenzen?
  • Möchten Sie Features mit einem Pool von Nutzern testen, um bestimmte Geschäftshypothesen gegenzuprüfen? Können Sie steuern, ob ausgewählte Nutzer das Update akzeptieren? Aktualisierungen auf Mobilgeräten erfordern beispielsweise explizite Nutzeraktionen und möglicherweise zusätzliche Berechtigungen.
  • Sind Mikrodienste in Ihrer Umgebung vollständig autonom? Oder haben Sie eine Kombination aus zusammenarbeitenden Anwendungen, die einerseits Mikrodiensten gleichkommen und andererseits einem herkömmlichen, schwierig zu ändernden Muster folgen? Weitere Informationen finden Sie unter Bereitstellungsmuster für Hybrid- und Multi-Cloud-Umgebungen.
  • Enthält der neue Release Schemaänderungen? Falls ja, sind die Schemaänderungen zu komplex, um sie von den Codeänderungen zu entkoppeln?

In der folgenden Tabelle sind die herausragendsten Merkmale der Bereitstellungs- und Testmuster zusammengefasst, die weiter oben in diesem Dokument behandelt wurden. Bei der Abwägung der Vor- und Nachteile verschiedener Bereitstellungs- und Testansätze sollten Sie Ihre Unternehmensanforderungen und technologischen Ressourcen berücksichtigen und dann die Option auswählen, von der Sie am meisten profitieren.

Bereitstellungs- oder
Testmuster		 Keine Ausfallzeiten Tests mit realem Produktionstraffic Freigabe für Nutzer anhand von Bedingungen Rollback-Dauer Auswirkungen auf Hardware- und Cloud-Kosten
Neuerstellung
Version 1 wird beendet und Version 2 eingeführt.		 x x x Schnell aber disruptiv aufgrund von Ausfallzeiten Keine zusätzliche Einrichtung erforderlich
Rolling Update
Version 2 wird nach und nach eingeführt und ersetzt Version 1.		 ✓ x x Langsam Für Surge-Upgrades kann eine zusätzliche Einrichtung erforderlich sein
Blau/Grün
Version 2 wird zusammen mit Version 1 veröffentlicht. Nachdem Version 2 getestet wurde, wird der Traffic zu ihr umgeleitet.		 ✓ x x Sofort Blaue und grüne Umgebungen müssen gleichzeitig aufrechterhalten werden
Canary
Version 2 wird für einen Teil der Nutzer freigegeben, gefolgt von einem vollständigen Rollout.		 ✓ ✓ x Schnell Keine zusätzliche Einrichtung erforderlich
A/B
Version 2 wird unter bestimmten Bedingungen für einen Teil der Nutzer freigegeben.		 ✓ ✓ ✓ Schnell Keine zusätzliche Einrichtung erforderlich
Shadow
Version 2 erhält realen Traffic, ohne dass sich Auswirkungen auf Nutzeranfragen ergeben.		 ✓ ✓ x Nicht zutreffend Sie müssen keine parallelen Umgebungen pflegen, um Nutzeranfragen erfassen und wiedergeben zu können

Best Practices

Anwendungsteams können verschiedenen Best Practices folgen, um die Risiken bei der Bereitstellung und bei Tests zu minimieren:

  • Abwärtskompatibilität. Wenn Sie mehrere Anwendungsversionen gleichzeitig ausführen, achten Sie darauf, dass die Datenbank mit allen aktiven Versionen kompatibel ist. Beispiel: Ein neuer Release erfordert einen Schemawechsel in der Datenbank (etwa eine neue Spalte). In einem solchen Szenario müssen Sie das Datenbankschema ändern, sodass es mit der älteren Version abwärtskompatibel ist. Nachdem Sie mit dem vollständigen Rollout fertig sind, können Sie die Unterstützung für das alte Schema entfernen, sodass nur noch die neueste Version unterstützt wird. Eine Möglichkeit, um Abwärtskompatibilität zu erreichen, besteht darin, Schemaänderungen von den Codeänderungen zu entkoppeln. Weitere Informationen finden Sie in den Mustern zur parallelen Änderung und Refaktorierung von Datenbanken.
  • Continuous Integration/Continuous Deployment (CI/CD). CI sorgt dafür, dass Code, der in den Feature-Branch eingecheckt wird, erst dann mit seinem Haupt-Branch zusammengeführt wird, wenn Abhängigkeitsprüfungen, Einheiten- und Integrationstests und der Build-Prozess erfolgreich durchlaufen wurden. Daher wird jede Änderung an einer Anwendung getestet, bevor sie bereitgestellt werden kann. Bei CD ist das anhand von CI erstellte Codeartefakt gepackt und fertig, um in einer oder mehreren Umgebungen bereitgestellt zu werden. Weitere Informationen finden Sie unter CI/CD-Pipeline mit Google Cloud erstellen.
  • Automation. Wenn Sie den Nutzern Anwendungsupdates kontinuierlich bereitstellen, empfehlen wir Ihnen, einen automatisierten Prozess einzurichten, mit dem die Software zuverlässig erstellt, getestet und bereitgestellt wird. Wir empfehlen außerdem, dass Ihre Codeänderungen automatisch durch eine CI/CD-Pipeline fließen, die Artefakterstellung, Einheitentests, Funktionstests und Produktionsrollout umfasst. Mit Automatisierungstools wie Cloud Build, Cloud Deploy, Spinnaker und Jenkins können Sie die Bereitstellungsprozesse automatisieren, damit sie effizienter, zuverlässiger und vorhersehbarer sind.
  • IaC und GitOps: Wenn Sie komplizierte Bereitstellungs- und Teststrategien verwalten müssen, sollten Sie die Verwendung von Infrastruktur als Code (IaC) und GitOps-Tools in Betracht ziehen. Die Verwendung von Terraform und Config Connector kann Ihnen dabei helfen, mit deklarativer Sprache Ihre Infrastruktur und Strategien zu definieren. Die Verwendung von GitOps mit Config Sync und Argo CD kann Ihnen bei der Verwaltung Ihres Codes mit Git helfen.
  • Rollback-Strategie. Manchmal geht etwas schief. Wir empfehlen die Erstellung einer Rollback-Strategie für den Fall, dass unerwartetes Verhalten auftritt. Eine zuverlässige Rollback-Strategie kann Administratoren und DevOps-Entwicklern beim Risikomanagement helfen. Sie können eine Rollback-Strategie mithilfe einer Plattform erstellen, die Rollbacks als integriertes Feature unterstützt, z. B.App Engine undCloud Run. Zur Unterstützung Ihrer Rollback-Anforderungen können Sie auch Tools zur Releaseautomatisierung wie Cloud Deploy, Spinnaker und Argo Rollouts verwenden.
  • Monitoring nach der Bereitstellung. Erstellen Sie mithilfe der Google Cloud Observability ein Monitoringsystem, um wichtige Messwerte zu überwachen und das zuständige Team zu benachrichtigen, wenn eine Bereitstellung oder ein Test fehlschlägt. Sie können auch automatisierte Rollbacks für Bereitstellungen aktivieren, bei denen Systemdiagnosen fehlschlagen. Mithilfe von Error Reporting, Cloud Trace und Cloud Profiler können Sie Ursache einfacher und komplexer Probleme nach der Bereitstellung ermitteln.

Nächste Schritte