In diesem Artikel skizzieren wir einen robusten und effizienten Release-Prozess für Webanwendungen, der auf einer Trunk-basierten Entwicklung und umgebungsbasierten Feature-Flags basiert. Diese Methodik gew?hrleistet eine kontinuierliche Integration, einfache Tests in der Produktion und einen reibungslosen Weg von der Entwicklung bis zur Ver?ffentlichung unter Beibehaltung hoher Qualit?tsstandards.

Grundprinzipien

1. Stammbasierte Entwicklung:

   • Der Stammzweig dient als einzige Quelle der Wahrheit für die gesamte Entwicklungsarbeit.
   • Entwickler erstellen Feature-Branches (z. B. feature/xyz) aus dem Trunk für neue Features oder Jira-Tickets.
   • Pull-Anfragen (PRs) werden von diesen Feature-Branches an den Trunk übermittelt, um sie nach erfolgreichen Tests zu überprüfen und zusammenzuführen.

2. Umgebungsbasierte Funktionsflags:

   • Feature-Flags werden verwendet, um die Aktivierung von Funktionen in verschiedenen Umgebungen zu steuern.
   • Flags werden in umgebungsspezifischen Konfigurationsdateien oder als Teil der CI/CD-Pipeline-Konfiguration gespeichert.
   • Im Trunk-Zweig sind alle Funktionsflags standardm??ig auf AUS gesetzt.
   • Flags k?nnen in bestimmten Umgebungen (z. B. Sandbox, Staging oder Produktion) nach Bedarf EIN ??umgeschaltet werden.

JIRA-Versionen im Sprint

Umgebungsbereitstellungsablauf

1. Sandbox oder Staging-Umgebung:

   • Für Qualit?tssicherungs- und Integrationstests k?nnen Teams aus dem Stamm einen Zweig mit dem Pr?fix ?sandbox/“ (z. B. ?sandbox/xyz“) erstellen.
   • Dieser Zweig wird mithilfe von CI/CD-Pipelines in einer dedizierten Sandbox oder Staging-Umgebung bereitgestellt.
   • QA-Teams k?nnen neue Funktionen validieren und Integrationstests k?nnen die Kompatibilit?t sicherstellen.
   • Feature-Flags werden in dieser Umgebung EIN ??umgeschaltet, um bestimmte Funktionen zu testen.

2. Vorbereitung der Produktionsfreigabe:

   • Um sich auf eine Ver?ffentlichung vorzubereiten, erstellen Sie einen Release/xyz-Zweig aus dem Stamm.
   • Der Release/xyz-Zweig dient als Release-Kandidat und wird zun?chst für 5 % des Produktionsverkehrs für Betatests bereitgestellt.
   • Feature-Flags für neue Funktionen werden in diesem Zweig EIN ??umgeschaltet, um Tests in der Produktion zu erm?glichen.
   • Nginx oder ein ?hnlicher Load Balancer kann diese Verkehrsaufteilung bew?ltigen und stellt sicher, dass nur eine Teilmenge der Benutzer die ?nderungen sieht.

Feature-Flags: Beispiele und Verwendung

1. Flag-Struktur:

   • Speichern Sie Feature-Flags in einer Konfigurationsdatei (z. B. config/feature-flags.json):

    {
      "feature_xyz": false,
      "feature_abc": true
    }
   

• Verwenden Sie Umgebungsvariablen, um Flags w?hrend der Laufzeit zu steuern:
  

   FEATURE_XYZ=true FEATURE_ABC=false npm start
  

1. Backend-Beispiel:

   • Flags im Code umschalten:

    const featureFlags = require('./config/feature-flags');
   
    if (featureFlags.feature_xyz) {
        console.log('Feature XYZ is enabled!');
    } else {
        console.log('Feature XYZ is disabled.');
    }
   

2. Frontend-Beispiel:

   • Verwenden Sie Flags, um UI-Komponenten bedingt zu rendern:

    if (process.env.REACT_APP_FEATURE_XYZ === 'true') {
        render(<NewFeatureComponent />);
    } else {
        render(<OldFeatureComponent />);
    }
   

3. Flags w?hrend des Tests umschalten:

   • Um ein Flag zum Testen umzuschalten, aktualisieren Sie die Konfigurations- oder Umgebungsvariablen und starten Sie den entsprechenden Dienst (Frontend oder Backend) neu:

    FEATURE_XYZ=true npm start
   

• Stellen Sie bei CI/CD-Pipelines sicher, dass w?hrend der Bereitstellung die entsprechenden Flag-Werte in die Umgebung eingefügt werden.

Testen in der Produktion

1. Traffic-Routing für Betatests:

   • Verwenden Sie Nginx-Konfigurationen, um die Verkehrszuteilung zu steuern:

    http {
        upstream stable_backend {
            server stable_backend_1;
            server stable_backend_2;
        }
   
        upstream canary_backend {
            server canary_backend_1;
            server canary_backend_2;
        }
   
        upstream mixed_backend {
            server stable_backend_1 weight=45;
            server stable_backend_2 weight=45;
            server canary_backend_1 weight=5;
            server canary_backend_2 weight=5;
        }
   
        server {
            listen 80;
            server_name my-app.example.com;
   
            location / {
                if ($http_x_qa_test = "true") {
                    proxy_pass http://canary_backend;
                    break;
                }
   
                proxy_pass http://mixed_backend;
            }
        }
    }
   

• Leiten Sie 5 % des Produktionsdatenverkehrs zu Servern, auf denen die neue Version ausgeführt wird, indem Sie die Lastausgleichsgewichte anpassen.

1. Dedizierte QS-Tests in der Produktion:
   • QA-Teams k?nnen ihren Anfragen ein benutzerdefiniertes Cookie (z. B. qa-test=true) hinzufügen.
   • Nginx überprüft dieses Cookie und leitet diese Anfragen zu 100 % an die neue Version weiter, um gezielte Tests in der Produktion sicherzustellen.

Stabilisierung der Freisetzung

1. Probleme beheben:

   • Entwickler beheben alle w?hrend des Betatests festgestellten Probleme, indem sie PRs für den Trunk-Zweig ?ffnen.
   • Nach der Zusammenführung werden diese Fixes in den Zweig ?release/xyz“ aufgenommen.

2. Abschluss der Ver?ffentlichung:

   • Nachdem alle Probleme gel?st sind und der Zweig stabil ist, wird der Release-Zweig mit einer semantischen Version (z. B. v1.2.0) getaggt, wodurch die Bereitstellung im stabilen Backend ausgel?st wird.
   • Versionshinweise werden zur Dokumentation erstellt und mit Stakeholdern geteilt.

Hotfix-Prozess

1. Hotfix-Zweige erstellen:

   • Für dringende Korrekturen erstellen Sie einen Hotfix/xyz-Zweig direkt aus dem neuesten Produktions-Tag.
   • Hotfix-Zweige folgen demselben Stabilisierungs- und Tagging-Prozess wie Release-Zweige.

2. Versionierung:

   • Hotfixes erh?hen die Patch-Version (z. B. von v1.2.0 auf v1.2.1) gem?? den Semantic Versioning (SemVer)-Standards.

Zweigbereinigung

• L?schen Sie zusammengeführte Zweige routinem??ig, um Unordnung zu vermeiden.
• Entfernen Sie nicht verwendete Funktionsflags regelm??ig, um die Organisation aufrechtzuerhalten.
• Automatisieren Sie das L?schen von Zweigen nach dem Zusammenführen mit GitHub Actions oder ?hnlichen Tools.

Alternative Qualit?tssicherungs- und Teststrategien

Anstelle von Cookies gibt es weitere Strategien zur Weiterleitung des QA-Verkehrs in der Produktion:

1. Header-basiertes Routing:

   • Die Qualit?tssicherung fügt ihren Anfragen einen benutzerdefinierten Header (z. B. X-QA-Test: true) hinzu.
   • Nginx leitet diese Anfragen zum Testen an die neue Version weiter.

2. IP-basiertes Routing:

   • Beschr?nken Sie den Datenverkehr auf die neue Version basierend auf den IP-Adressen der QA.

3. Authentifizierungstoken-basiertes Routing:

   • QA meldet sich mit einem bestimmten Testkonto an, das an eine Rolle oder ein Token gebunden ist, das sicherstellt, dass Anfragen an die neue Version weitergeleitet werden.

Fazit

Dieser Release-Prozess nutzt Trunk-basierte Entwicklung und umgebungsbasierte Feature-Flags, um einen skalierbaren, testbaren und produktionssicheren Bereitstellungsworkflow zu erstellen. Durch den Einsatz von Sandbox-Umgebungen, Traffic-Routing und dedizierten Teststrategien k?nnen Teams hochwertige Funktionen bereitstellen und gleichzeitig das Risiko minimieren. Der Ansatz stellt sicher, dass Probleme frühzeitig erkannt und effizient behoben werden, und ebnet so den Weg für nahtlose Funktionseinführungen und Hotfixes.

Das obige ist der detaillierte Inhalt vonOptimierter Release-Prozess für eine Webanwendung: Trunk-basierte Entwicklung mit Feature-Flags. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!