Produktionsupgrade-Strategien für Jitterbit App Builder

Einführung

Ein Upgrade von App Builder bedeutet, eine neue Plattformversion in der App Builder-Umgebung zu installieren, einschließlich aller erforderlichen Updates der Vinyl-Datenbank (die zugrunde liegende Datenbank von App Builder). Da ein Upgrade die Laufzeit der Anwendung und das Datenbankschema gleichzeitig ändert, hilft eine sorgfältige Planung dabei, Kompatibilitätsprobleme frühzeitig zu erkennen und die Ausfallzeit vorhersehbar zu halten.

Der beste Ansatz besteht darin, eine Plattformversion zunächst in einer produktionsfremden Umgebung zu validieren. Führen Sie mindestens eine duale Umgebungstopologie (Entwicklung und Produktion) oder eine dreistufige Umgebungstopologie (Entwicklung, QA und Produktion) gemäß dem 3-stufigen Ansatz durch, um Plattformversionen, Datenbankschema-Migrationen und benutzerdefinierte Anwendungslogik vor der Produktionsumgebung zu testen. Der Betrieb einer einzelnen produktionsgebundenen Umgebung wird dringend abgeraten, da keine Umgebung vorhanden ist, um Probleme zu erkennen, bevor sie Benutzer beeinflussen.

Diese Seite listet die Voraussetzungen für ein Upgrade auf und beschreibt dann den Prozess in drei Schritten:

1. Schritt 1: Upgrade und Validierung von Entwicklung und QA
   Führen Sie ein Upgrade der Plattformversion in den Entwicklungs- und QA-Umgebungen durch und validieren Sie es dort.

2. Schritt 2: Upgrade der Produktion
   Wählen Sie eine Strategie für das Upgrade der Produktionsumgebung: ein direktes Upgrade oder eine Blue/Green-Bereitstellung.

3. Schritt 3: Upgrade überprüfen
   Stellen Sie sicher, dass das Upgrade erfolgreich war.

Wenn Sie nur eine Produktionsumgebung verwalten, finden Sie unter Einzelumgebung (nur Produktion) Bereitstellungen Hinweise zur Anpassung der folgenden Schritte.

Voraussetzungen

Führen Sie vor einem Plattformupgrade in einer beliebigen Umgebung die folgenden Schritte in dieser Reihenfolge aus:

1. Code-Freeze: Führen Sie einen Code-Freeze in allen Umgebungen durch. Starten Sie keine neue Anwendungsfeature-Entwicklung, bis das Plattformupgrade in allen Umgebungen abgeschlossen ist.

2. Datenbankschema-Synchronisierung: Stellen Sie sicher, dass benutzerdefinierte Datenbankschemas (Tabellen, Spalten, Ansichten und gespeicherte Prozeduren) zwischen Entwicklung, QA und Produktion synchronisiert sind. Schema-Drift zwischen Umgebungen kann dazu führen, dass das Plattformupgrade oder die Anwendungslogik unvorhersehbar fehlschlägt. Weitere Informationen dazu, wie App Builder Schemaänderungen über Umgebungen hinweg verfolgt und wiederholt, finden Sie unter Release-Management.

3. Systemanforderungen überprüfen: Überprüfen Sie, dass die Host-Umgebung die Systemanforderungen für die Zielversion erfüllt, über Betriebssysteme, Container-Laufzeiten und Datenbank-Engines hinweg.

4. Datenbank-, Datei- und Ordner-Sicherungen: Führen Sie unmittelbar vor Wartungsbeginn folgende Schritte aus:

   • Sichern Sie die Vinyl-Datenbank (erforderlich) und alle Anwendungsdatenbanken, die physische oder Schemaänderungen durchlaufen (dringend empfohlen).

   • Bewahren Sie eine Kopie der vorherigen Release-Archivdatei (.tar.gz oder .zip) oder des vorherigen Anwendungsordners selbst auf dem Host auf. Beide ermöglichen ein schnelles Rollback: Extrahieren Sie das Archiv erneut oder tauschen Sie den alten Ordner zurück.

   • Bewahren Sie die folgenden Inhalte des App Builder-Anwendungsverzeichnisses beim Ersetzen von Anwendungsbinärdateien oder beim Upgrade von Verzeichnissen:

     • appsettings.json: Behält die Konfigurationseinstellungen auf Anwendungsebene bei.

     • Connection.xml: Behält die Backend-Datenbankverbindungszeichenfolgen und -parameter bei.

     • data: Enthält lokal gespeicherte Anwendungsdateien, z. B. generierte PDFs, Datei-Uploads und andere im App Builder-Verzeichnis gespeicherte Dokumentanhänge.

     • keys: Enthält die Datenverschlüsselungsschlüssel, die zum Entschlüsseln gespeicherter Anmeldeinformationen, Verbindungszeichenfolgen und Anwendungsdaten verwendet werden. Der Verlust dieses Ordners macht verschlüsselte Daten dauerhaft unlesbar.

     • Lizenzdatei (vinyl.lic): Vermeidet Lizenzierungsfehler beim Start.

5. logs: Behält Systemereignisprotokolle, Diagnoseprotokolle und Audit-Trails bei.

Nachdem diese Voraussetzungen erfüllt sind, fahren Sie mit Schritt 1: Upgrade und Validierung von Entwicklung und QA fort.

Schritt 1: Upgrade und Validierung von Entwicklung und QA

Führen Sie vor dem Upgrade der Produktion unter einer der beiden Strategien das Plattform-Upgrade in der Entwicklungs- und QA-Umgebung durch und validieren Sie es dort. Dies ermöglicht es Entwicklern und Business-Benutzern, Kompatibilitätsprobleme zu erkennen, bevor die Änderung die Produktion erreicht, unabhängig davon, welche Strategie Sie später für das Produktions-Upgrade wählen.

Aktualisieren Sie die Entwicklungs- oder QA-Datenbank (optional)

Stellen Sie als zusätzliche Vorsichtsmaßnahme vor dem Upgrade dieser Umgebungen eine frische Kopie der Produktionsdatenbank in der Entwicklungs- oder QA-Umgebung wieder her:

• Wiederherstellung in der Entwicklung für einen Migrations-Testlauf: Dies ermöglicht es Entwicklern, Schema-Updates gegen echte Produktionsdaten zu testen, datenbezogene Konflikte frühzeitig zu erkennen und die Ausführungszeit zu messen, um das Produktions-Ausfallzeitfenster zu planen.

• Wiederherstellung in QA für realistische User Acceptance Testing (UAT): Dies stellt sicher, dass Business-Benutzer UAT gegen authentische Produktionsdaten-Szenarien durchführen.

Aktualisieren Sie die Entwicklungsumgebung und führen Sie Smoke Testing durch

Das Upgrade der Entwicklungsumgebung zuerst ermöglicht es Entwicklern, das neue Plattform-Release gegen echte Anwendungslogik zu validieren und Kompatibilitätsprobleme zu beheben, bevor sie QA oder Produktion erreichen.

1. (Optional) Aktualisieren Sie die Entwicklungsdatenbank gemäß der obigen Anleitung.

2. Aktualisieren Sie die App Builder-Laufzeit und -Datenbank in der Entwicklung.

3. Führen Sie Smoke Testing auf der aktualisierten Instanz durch und konzentrieren Sie sich auf die folgenden Bereiche:

   • Zentrale Geschäftsprozesse: Die Geschäftslogik basiert häufig auf Funktionen auf Datenbankebene, dynamischer SQL-Generierung oder gespeicherten Prozeduren. Ein Versions-Upgrade kann ändern, wie Datenbankabfragen ausgeführt werden. Validieren Sie daher Ihre Kernpfade.

   • Datenquellenverbindungen und Integrationen: Plattform-Updates enthalten häufig aktualisierte Datenbanktreiber, Open Database Connectivity (ODBC)- oder Java Database Connectivity (JDBC)-Konnektoren oder überarbeitete Authentifizierungsanforderungen. Überprüfen Sie, dass alle Remote-Datenquellen sauber verbunden und abgefragt werden.

   • UI- und UX-Elemente (Designs, HTML, CSS, Layouts): Plattform-Updates können interne Document Object Model (DOM)-Strukturen oder Standard-Elementselektoren ändern. Benutzerdefinierte Stile und Overrides können unterbrochen werden, wenn sich strukturelle Klassen oder Selektoren ändern.

   • Benutzerdefinierter Code (UI-Widgets, Plugins, benutzerdefiniertes JavaScript): Benutzerdefinierter Code birgt während eines Upgrades das höchste Risiko, da Jitterbit QA Code, der außerhalb der Kernplattform geschrieben wurde, nicht testen kann. Testen Sie alle interaktiven UI-Komponenten, um zu bestätigen, dass sich ihre APIs oder DOM-Ziele nicht verschoben haben.

   • Sicherheit, Rollen und Berechtigungen auf Zeilenebene: Plattform-Releases aktualisieren manchmal die Sicherheitsbewertungslogik oder Sicherheitsfilter auf Zeilenebene. Überprüfen Sie, dass Benutzerrollen, Identitätswechselregeln und Datenzugriffsrichtlinien wie erwartet funktionieren.

   • Geplante Ereignisse, Hintergrund-Jobs und Warteschlangen: Bestätigen Sie, dass automatisierte Aufgaben ausgelöst werden und bis zum Abschluss ausgeführt werden, da Änderungen an der Konfiguration des Hintergrund-Service diese beeinflussen können.

   • Plattform-Versionshinweise: Lesen Sie die App Builder-Versionshinweise auf Veraltungen, Breaking Changes und erforderliche Schritte nach dem Upgrade.

4. Wenn Entwickler während des Smoke Testing Kompatibilitätsprobleme finden, beheben Sie die erforderlichen Probleme in der Entwicklung und erstellen Sie dann ein Release-Paket, um die Fixes in QA und Produktion bereitzustellen.

Aktualisieren Sie QA und führen Sie UAT durch

Mit der validierten Entwicklungsumgebung wird in diesem Schritt QA auf die gleiche Plattformversion gebracht, die während der Entwicklung erstellten Fixes werden bereitgestellt, und Geschäftsbenutzer erhalten die Möglichkeit, die Lösung freizugeben, bevor die Produktion berührt wird.

1. (Optional) Aktualisieren Sie die QA-Datenbank gemäß der obigen Anleitung.

2. Aktualisieren Sie die App Builder-Laufzeit und -Datenbank in QA.

3. Stellen Sie das Release-Paket bereit, das die aus der Entwicklung exportierten Fixes enthält. Die Installation eines Release-Pakets erfordert eine kurze zusätzliche Ausfallzeit für die betroffenen Anwendungen.

4. Führen Sie vollständige UAT durch, um die Anwendungsfunktionalität zu validieren und die Bereitstellungsfreigabe zu erhalten.

Nachdem Entwicklung und QA aktualisiert und validiert wurden, fahren Sie mit Schritt 2: Produktion aktualisieren fort.

Schritt 2: Produktion aktualisieren

Mit der aktualisierten und validierten Entwicklung und QA sowie Ihrem bereiten Release-Paket wählen Sie eine der folgenden Strategien für die Produktionsaktualisierung:

• Direktes Upgrade: Wendet das Plattform-Upgrade direkt auf die Produktion während eines Wartungsfensters an. Empfohlen für Standard-Entwicklungs-, QA- und Produktionstopologien.

• Blue/Green-Bereitstellung: Aktualisiert eine parallele Kopie der Produktion (Green), während die Live-Umgebung (Blue) weiterhin Benutzer bedient, und wechselt dann den Datenverkehr, sobald Green verifiziert ist. Empfohlen für unternehmenskritische Umgebungen, die minimale Ausfallzeiten erfordern.

Die folgende Tabelle vergleicht die beiden Strategien:

Direktes Upgrade

Empfohlen für Standard-Entwicklungs-, QA- und Produktionstopologien mit einem geplanten Wartungsfenster. Diese Strategie wendet das Plattform-Upgrade direkt auf die Live-Infrastruktur der Produktion an, nachdem das Release bereits in Entwicklung und QA aktualisiert und validiert wurde.

Wenden Sie zunächst das Plattform-Update und die in Entwicklung und QA validierten Fixes auf die Produktion während Ihres geplanten Wartungsfensters an. Führen Sie diese Schritte aus:

1. Beenden Sie Internet Information Services (IIS), Anwendungsdienste oder Container in der Produktion, um eingehenden Datenverkehr zu stoppen.

2. Sichern Sie die Produktionsdatenbanken und bewahren Sie die in Voraussetzungen aufgeführten Kerndateien auf.

3. Aktualisieren Sie die Anwendungs-Laufzeit für Ihre Umgebung:

   • AWS: Stellen Sie das neue Anwendungs-Bundle bereit oder aktualisieren Sie das Ziel-Image-Tag gemäß App Builder in AWS installieren.

   • Azure: Aktualisieren Sie das Container-Image-Tag oder das Anwendungspaket gemäß App Builder in Microsoft Azure installieren.

   • Docker: Aktualisieren Sie das Image-Tag in docker-compose.yml, behalten Sie die Volume-Mounts bei, die keys, logs, data, Connection.xml und appsettings.json persistieren, und pullen und starten Sie die Container neu. Siehe Upgrade auf App Builder in Docker.

4. Google Cloud Platform (GCP): Stellen Sie das neue Container-Image-Tag in Cloud Run, Google Kubernetes Engine (GKE) oder Compute Engine bereit.

5. Windows/IIS: Folgen Sie App Builder unter Microsoft Windows aktualisieren, das die Wiederherstellung von Connection.xml, appsettings.json und dem Ordner keys sowie die Gewährung von Vollzugriff für die IIS-Anwendungspoolidentität auf die Verzeichnisse data, logs und keys behandelt.

6. Starten Sie die Dienste, um die aktualisierte Plattform online zu bringen.

7. Stellen Sie das Release-Paket mit den in Entwicklung und QA validierten Fixes bereit. Berücksichtigen Sie die kurze zusätzliche Ausfallzeit, die dies erfordert.

8. Führen Sie die Überprüfungen in Schritt 3: Upgrade überprüfen durch, leeren Sie Anwendungs-Caches und öffnen Sie die Umgebung wieder für Benutzer.

Rollback eines direkten Upgrades

Wenn das Produktions-Upgrade fehlschlägt oder kritische Probleme verursacht, führen Sie diese Schritte aus, um die Produktion in ihren Zustand vor dem Upgrade zurückzuversetzen.

1. Beenden Sie Anwendungsdienste, IIS oder Container.

2. Stellen Sie die Vinyl-Datenbank und Anwendungsdatenbanken aus den Sicherungen vor dem Upgrade wieder her.

   Warnung

   Das Wiederherstellen von Datenbanksicherungen setzt alle Benutzeraktivitäten oder Transaktionen zurück, die nach dem Upgrade aufgezeichnet wurden.

3. Setzen Sie die Anwendungslaufzeit zurück:

   • Windows/IIS: Ersetzen Sie das Anwendungsverzeichnis durch den gespeicherten Sicherungsordner, oder extrahieren Sie das vorherige Release-Archiv erneut, wobei Sie keys, logs, data, Connection.xml, appsettings.json und die Lizenzdatei intakt halten.

   • Docker oder Cloud-Container (AWS, GCP, Azure): Setzen Sie das vorherige Release-Tag in Ihrer Compose-Datei, Cloud Run, GKE oder App Service-Konfiguration zurück und stellen Sie es erneut bereit.

4. Starten Sie die Dienste und führen Sie grundlegende Überprüfungen durch, bevor Sie die Umgebung wieder öffnen.

Blue/Green-Bereitstellung

Empfohlen für unternehmenskritische Produktionsumgebungen, die hohe Verfügbarkeit und minimale Wartungsfenster erfordern.

Blue/Green ist eine Bereitstellungsstrategie für die Produktionsphase Ihres Lebenszyklus. Sie ersetzt nicht das Testen in Nicht-Produktionsumgebungen: Führen Sie die Voraussetzungen und Schritt 1: Upgrade und Validierung von Entwicklung und QA durch, bevor Sie einen Blue/Green-Cutover in der Produktion starten. (Dies gilt nicht, wenn Sie Blue/Green für eine Bereitstellung in einer einzelnen Umgebung anpassen.)

Diese Strategie aktualisiert Green, während Blue online bleibt, und führt dann einen Cutover durch, sobald Green überprüft ist. Erwarten Sie minimale Ausfallzeit, begrenzt auf die endgültige Datenbanksynchronisierung und den DNS- oder Load-Balancer-Cutover.

Stellen Sie zunächst die Green-Umgebung bereit. Green muss als unabhängige Umgebung vorhanden sein, konfiguriert wie Blue, aber noch keinen Live-Traffic bedienend, bevor Sie das neue Release darauf aktualisieren und validieren können. Führen Sie diese Schritte aus:

1. Fügen Sie auf Blue vor dem Klonen einen Site-Eintrag für Green hinzu, damit Green die Umleitung von Blue nicht erbt. Wählen Sie Security Providers > More > Sites, klicken Sie auf + Site, und erstellen Sie einen Eintrag mit der URL von Green, wobei Sie Default und Redirect deaktiviert lassen. Sobald Green von Blue geklont wird, stimmen Anfragen an die eigene URL von Green mit diesem Eintrag überein, anstatt auf den standardmäßigen, umleitungsaktiven Eintrag von Blue zurückzugreifen. (Weitere Informationen zu dieser Funktion finden Sie unter Sites und Aliase.)

2. Stellen Sie Green als vollständigen Klon von Blue bereit, einschließlich seiner Vinyl-Datenbank zu diesem Zeitpunkt (mit seinen aktuellen Verschlüsselungsschlüsseln, Workflow-Verlauf, Job-Verlauf und Protokollen).

3. Aktualisieren Sie Connection.xml, appsettings.json und Umgebungsvariablen von Green, um während des Staging auf die Green-Datenbankinstanz zu verweisen, nicht auf die Live-Blue-Datenbank.

{
  "Site": {
    "Url": "https://localhost:5001",
    "Default": true,
    "Redirect": false,
    "Aliases": [
      {
        "Url": "https://localhost:5000"
      }
    ]
  }
}

Wenden Sie das Upgrade anschließend auf Green an und validieren Sie es anhand von Produktionsdaten. An diesem Punkt sind die Benutzer, die Blue weiterhin bedient, noch nicht betroffen. Führen Sie diese Schritte aus:

1. Klonen Sie die Produktionsdatenbanken auf Green.

2. Wenden Sie das Plattform-Upgrade, Container-Updates und Datenbankmigrationen auf Green an.

3. Stellen Sie das Release-Paket bereit, das die in Entwicklung und QA validierten Fixes enthält.

4. Wenn Ihre Anwendungen Hintergrund-Jobs ausführen, die E-Mail-Benachrichtigungen versenden, deaktivieren Sie diese Jobs oder passen Sie die SMTP-Servereinstellungen auf Green während der Validierung an, um zu verhindern, dass doppelte E-Mails an Benutzer gesendet werden, während Blue noch aktiv ist.

5. Führen Sie die Validierung und Integritätsprüfungen auf Green durch, während Blue weiterhin Live-Traffic verarbeitet.

Nachdem Green vollständig validiert ist, ist es Zeit, die letzten Produktionsänderungen zu synchronisieren und den Live-Traffic von Blue zu Green zu wechseln:

1. Unterbrechen Sie Schreibvorgänge auf Blue oder stoppen Sie kurzzeitig die Blue-Anwendungsdienste.

2. Erstellen Sie ein finales Backup der Benutzerdatenbanken (Anwendungsdatenbanken) von Blue und stellen Sie es auf Green wieder her, um vollständige Datenkonsistenz zu erreichen. Jitterbit empfiehlt ein vollständiges Backup und eine vollständige Wiederherstellung. Eine differenzielle Sicherung wird nur empfohlen, wenn das Datenvolumen ein vollständiges Backup unpraktisch macht.

3. Synchronisieren Sie Verschlüsselungsschlüssel zwischen Blue und Green:

   • Wenn Schlüssel an einem externen Ort gespeichert sind, z. B. in einem S3-Bucket, teilen Blue und Green diese bereits, und es ist keine Aktion erforderlich.

   • Wenn Schlüssel im Dateisystem gespeichert sind (Standard), kopieren Sie die Key Encryption Keys (KEKs) jetzt von Blue zu Green.

   • Öffnen Sie für jede Datenquelle die Registerkarte „Datenquellen", wählen Sie die Zeile der Datenquelle aus, und wählen Sie dann Verschlüsselungsschlüssel unter Business Logic Layer aus, um nach Data Encryption Key (DEK)-Datensätzen zu suchen, die erstellt wurden, nachdem Green bereitgestellt wurde:

     Für alle neuen Datensätze muss ein Administrator sich direkt mit der Vinyl-Datenbank von Blue verbinden, den Schlüssel aus der Tabelle Se_DataEncryptionKey exportieren und ihn in die Vinyl-Datenbank von Green importieren.

   Warnung

   Eine laufende Produktionsumgebung muss jeden über ihre Lebensdauer generierten Verschlüsselungsschlüssel beibehalten, sonst werden die von ihm verschlüsselten Daten dauerhaft unlesbar.

4. Aktivieren Sie alle SMTP-Einstellungen oder Hintergrund-Jobs erneut, die Sie auf Green während des Staging angepasst haben.

5. Wärmen Sie die Anwendungspools oder Container auf Green auf.

6. Verweisen Sie DNS-Einträge, Load Balancer oder Reverse Proxies von Blue zu Green um.

7. Führen Sie die Prüfungen in Schritt 3: Upgrade überprüfen durch, überwachen Sie den Traffic auf Green, und deaktivieren oder fahren Sie Blue herunter, sobald die Stabilität überprüft ist.

8. Nachdem Blue deaktiviert wurde, entfernen oder aktualisieren Sie den Site-Eintrag, den Green von Blue geerbt hat (den mit Standard und Umleitung aktiviert).

   Hinweis

   Wenn dieser Eintrag vorhanden bleibt, leitet er alle Anfragen, die nicht mit Greens eigenem Site-Eintrag übereinstimmen, zum jetzt deaktivierten Blue um.

Rollback eines Blue/Green-Cutover

Wenn Tests auf Green Probleme aufdecken oder unmittelbar nach dem Cutover ein kritisches Problem auftritt, müssen Sie möglicherweise zu Blue zurückkehren. Da Blue während Tests und Staging unverändert bleibt, ist ein Rollback unkompliziert, unabhängig davon, wann das Problem auftritt:

• Vor dem Cutover: Wenn Tests auf Green Probleme aufdecken, beenden Sie Green. Blue hat keine Auswirkungen oder Ausfallzeiten.

• Nach dem Cutover: Wenn unmittelbar nach dem Wechsel von DNS oder Routing kritische Probleme auftreten, verweisen Sie DNS oder Load Balancer zurück zu Blue. Gleichen Sie alle Schreibtransaktionen manuell ab, die auf Green nach dem Cutover zurück zu Blue aufgezeichnet wurden, bevor Sie zurücksetzen.

Single-Environment-Bereitstellungen (nur Produktion)

Wenn Sie eine Single-Environment-Bereitstellung (nur Produktion) haben, unterscheidet sich die Upgrade-Strategie etwas. Führen Sie zunächst die Punkte 1, 3 und 4 der Voraussetzungen durch: die Code-Freeze, die Systemanforderungsprüfung und die Backups, da diese alle für eine Single-Environment-Bereitstellung gelten. Punkt 2 (die Datenbankschema-Synchronisierung) gilt nicht, da es keine andere Umgebung gibt, mit der synchronisiert werden kann. Da eine Single-Environment-Bereitstellung keine Entwicklungs- oder QA-Umgebung hat, sollten Sie auch Schritt 1: Upgrade und Validierung von Entwicklung und QA überspringen. Wählen Sie stattdessen einen der folgenden Ansätze:

In-place-Upgrade in einer einzelnen Umgebung

Dieser Ansatz folgt denselben Runtime-Update-Schritten wie das In-place-Upgrade: Services stoppen, sichern, Anwendungs-Runtime aktualisieren und Services erneut starten. Überspringen Sie den Schritt, der ein in Entwicklung und QA erstelltes Release-Paket bereitstellt, da keines in einer Einzelumgebungs-Bereitstellung vorhanden ist. Stattdessen müssen Entwickler, die nach dem Upgrade Anwendungsprobleme feststellen, diese in der Live-Umgebung beheben, während Benutzer angemeldet sind, da Smoke-Tests direkt nach dem Upgrade in der Produktion stattfinden. Wenn das Upgrade selbst fehlschlägt, verwenden Sie dieselben Rollback-Schritte wie beim In-place-Upgrade.

Um zu verhindern, dass Benutzer auf Fehler oder beschädigte Workflows stoßen, während Entwickler Fixes anwenden, verwenden Sie den Maintenance-Guided-Workflow, um betroffene Anwendungen zu sperren und Nicht-Admin-Traffic auf eine Wartungsseite umzuleiten, bis Tests und Fixes abgeschlossen sind.

Blue/Green in einer einzelnen Umgebung

Wenn Sie eine Blue/Green-Strategie in einer Einzelumgebungs-Konfiguration verwenden, fungiert die Green-Umgebung als temporärer Test-Spielplatz. Entwickler führen das Plattform-Upgrade durch, führen vollständige Smoke-Tests durch und wenden alle erforderlichen Anwendungs-Fixes auf Green an, während Blue live bleibt und normalen Benutzer-Traffic verarbeitet.

Sobald Green vollständig getestet und verifiziert ist, synchronisieren Sie die endgültigen Datenbankänderungen und führen den Traffic-Cutover durch, indem Sie Blue/Green-Bereitstellung befolgen. Benutzer erleben keine fehlerhaften App-Zustände und sehen während des Fix-Zyklus keine Wartungsfenster.

Nachdem Sie das Upgrade mit einem der beiden Ansätze abgeschlossen haben, fahren Sie mit Schritt 3: Upgrade verifizieren fort.

Schritt 3: Upgrade verifizieren

Bevor Sie das Wartungsfenster beenden (wenn Sie das In-place-Upgrade verwendet haben) oder Blue außer Betrieb nehmen (wenn Sie Blue/Green-Bereitstellung verwendet haben), bestätigen Sie Folgendes:

• Die App Builder-Lizenz bleibt auf dem aktualisierten Release gültig und aktiv.

• Geplante Hintergrund-Jobs, Warteschlangen und Thread-Pool-Worker befinden sich in einem laufenden oder Leerlauf-Zustand und sind beim Start nicht fehlgeschlagen.

• Der Ordner logs zeigt keine unbehandelten Ausnahmen, Object-Relational Mapping (ORM)-Fehler oder Datenbankverbindungs-Timeouts.

• Die im Anwendungs-Footer oder auf der Diagnoseseite angezeigte App Builder-Version entspricht dem Ziel-Release.