Optimierter Release-Prozess für eine Webanwendung: Trunk-basierte Entwicklung mit Feature-Flags

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!