Feature Flags zum Testen in der Produktion verwenden
Einer meiner Lieblingsentwickler erzählte mir einmal, dass er seinen Code zwar robust testet, aber nur in der Produktion. Das mag manchen QA-Ingenieuren einen Herzinfarkt bescheren, aber ich möchte Ihnen ein kleines Geheimnis verraten: Bei Optimizely testen wir ständig in der Produktion. Wenn Sie das nicht tun, könnte es sein, dass Sie Ihr Unternehmen zu kurz kommen lassen.


Frank Hu - Senior Engineer, Optimizely - Er testet seinen Code in der Produktion
Einer meiner Lieblingsentwickler erzählte mir einmal, dass er seinen Code zwar gründlich testet, aber nur in der Produktion. Das mag einigen QA-Ingenieuren einen Herzinfarkt bescheren, aber ich möchte Ihnen ein kleines Geheimnis verraten: Bei Optimizely testen wir ständig in der Produktion. Wenn Sie das nicht tun, benachteiligen Sie möglicherweise Ihre Kunden.
In den meisten Unternehmen finden automatisierte und manuelle Tests in der Staging-Umgebung statt. Technische Unternehmen tun dies, weil beim Testen in der Produktionsumgebung Probleme auftreten können, die Schwachstellen an die Öffentlichkeit bringen oder ein schlechtes Erlebnis für die Benutzer schaffen, das den Ruf des Unternehmens schädigt.
Technische Unternehmen, die nicht in der Produktionsumgebung testen, überprüfen jedoch nicht, ob ihre Funktionen in der tatsächlichen Umgebung funktionieren, in der ihre Kunden sie verwenden.
Die synthetischen Daten, die in Staging-Umgebungen verwendet werden, werden sich nie zu 100 % wie echte Daten verhalten, und aus dieser Diskrepanz entstehen oft Fehler.
Wie sollten QA-Teams also in der Produktion testen, ohne sich diesen Unzulänglichkeiten auszusetzen? Unser Geheimrezept besteht darin, dass wir unsere Feature Management-Lösung verwenden, um unseren Code bereitzustellen, und dann unsere Feature Flag Audience Conditions als Berechtigungs-Toggle verwenden, um unsere Testteams einzuschalten.
Der gesamte Prozess sieht in etwa so aus:
Discover Why Forrester Recognized Optimizely as a Leader
1. Die Entwickler stellen den Code hinter einem Feature Flag bereit, wobei das Feature ausgeschaltet ist. Die neuen Funktionen werden nun in der Produktion eingesetzt, bleiben aber vor unseren Kunden verborgen.
2. QA erstellt Publikumsgruppen und fügt eine Publikumsbedingung mit unserer Testgruppe hinzu.
3. Diese Testgruppe besteht aus Customer Service Managern, Solution Architects und Geschäftsanwendern. Diese Benutzer haben den größten Bezug dazu, wie unsere Kunden unser Produkt verwenden oder wie sie unsere Kunden, die unser Produkt verwenden, unterstützen können. Außerdem verfügen sie über Daten in ihren Konten und Anwendungsfällen, die die meisten Entwickler und QA-Ingenieure nicht kennen.
4. Das QA-Team veranstaltet zusammen mit dieser Testgruppe einen Bug-Bash und erlaubt allen, gegen die neuen Funktionen zu bashen, um nach Fehlern zu suchen.
Da die neue Funktion mit einem Feature Flag versehen ist, können wir sie allen Benutzern zur Verfügung stellen, wenn keine größeren Fehler gefunden werden und wir sie der Öffentlichkeit zugänglich machen wollen. In Optimizely können Sie dies in einem Feature Dashboard mit zwei Klicks und Speichern tun.
Wenn größere Fehler gefunden werden, schalten wir das Feature einfach ab oder entfernen die Bedingung "Testgruppe". Auf diese Weise können die Benutzer in der Testgruppe wieder in den Codepfad vor der Veröffentlichung zurückversetzt werden, ohne dass wir einen Code-Rollback durchführen müssen.
Letztendlich sollten wir unseren Code in der Umgebung testen, die derjenigen, die unser Kunde tatsächlich verwendet, am ähnlichsten ist, ohne ihn dabei tatsächlichen Fehlern auszusetzen. Mit Feature Flags können wir nicht nur unseren Code immer testen, sondern auch in der Produktion!