Antworten:
Feature Flags sind ein Engineering-Gerät, mit dem sich langlebige Verzweigungen und Konflikte bei der Produktentwicklung vermeiden lassen. Auf diese Weise kann der Kontext einer objektorientierten Sprache verwendet werden, um Entwicklern bei der Zusammenarbeit an einem bestimmten Produktmerkmal zu helfen, während eine neue Version bearbeitet wird. Diese Lösung kann auch in nicht objektorientierten Kontexten verwendet werden, sofern der Begriff „Schnittstelle“ existiert. ( Siehe OCaml-Modulsystem.)
Zur Veranschaulichung wird von einem Tool ausgegangen, das Berichte über in einer Datenbank gespeicherte Daten präsentiert. Der Code implementiert eine DatabaseClient- Klasse, die zum Ausführen von Anforderungen verwendet wird. Mit dem Anwachsen des Datasets wird deutlich, dass ein alternatives Datenlayout die Anwendungsleistung verbessern würde. Daher wird Alice eine neue Version des DatabaseClient entwickeln, mit der Daten aus den Strukturen mit verbessertem Layout abgerufen werden können, während Bob den historischen DatabaseClient verwaltet .
Mit den folgenden Schritten können Alice und Bob an kurzlebigen Zweigen zusammenarbeiten und gleichzeitig ihre Konflikte minimieren.
Alice benennt DatabaseClient in DatabaseClient_v1 um und erstellt eine Delegatklasse mit dem Namen DatabaseClient , die ein Objekt DatabaseClient_v1 verwendet und eine Schnittstelle mit dem Namen DatabaseClientInterface implementiert . (Wenn möglich, sollte dieses DatabaseClientInterface ein Code-Artefakt sein, aber Sprachen, die vom Typ Ente stammen, unterstützen dies nicht immer.)
Bob überprüft die von Alice in 1 vorgenommenen Änderungen und ist sich bewusst, dass sein Wartungsauftrag auf DatabaseClient_v1 erfolgen sollte .
Alice führt ein neues Konfigurationsflag in der Anwendung ein, das das Verhalten des DatabaseClient- Delegaten steuert und einen DatabaseClient_v2- Platzhalter implementiert, eine Klasse, die das DatabaseClientInterface implementiert, dessen Methoden alle eine Ausnahme "Nicht implementiert" auslösen.
Danach können Alice und Bob ohne explizite Synchronisation zusammenarbeiten, da der in ihren jeweiligen Iterationen geschriebene Code dem DatabaseClientInterface unterliegt . Dies minimiert das Risiko eines Konflikts, der sich aus ihrer gleichzeitigen Arbeit ergibt.
Iterationen von Alice können sehr kurz sein, z. B. das Implementieren eines Tests, das Implementieren einer Methode oder auch nur teilweise, da der Code in der Produktion nicht für die Verwendung ausgewählt ist und nicht voll funktionsfähig sein muss. Die automatisierte Testsuite sollte so konfiguriert sein, dass DatabaseClientInterface immer DatabaseClient_v1 verwendet, während Alice beim lokalen Ausführen der Testsuite - oder in einem benutzerdefinierten CI-Setup - problemlos zu DatabaseClient_v2 wechseln kann. Sobald alles fertig ist, kann eine einzelne Festschreibung die Änderung durchführen, indem der Konfigurationswert für den DatabaseClient- Delegaten aktualisiert wird .
Die Schritte sind ganz "einfach". Um zu einer App mit Funktionsflaggen zu wechseln, müssen Sie im Grunde zwei Dinge tun:
Die Grundeinstellung für das Feature-Flag ist das Ein- und Ausschalten der Features. Sie möchten jedoch schnell ein neues Feature im Hochlauf freigeben, z. Anschließend schalten Sie die Funktion auf einem anderen Server ein, bis sie auf allen Servern aktiviert ist.
Dies bedeutet, dass Sie darauf achten müssen, dass Ihre Funktion mit der App ohne sie kompatibel ist (z. B. zusätzliche Spalte in der Datenbank).
Frameworks gibt es in verschiedenen Sprachen, um das Rad nicht neu zu erfinden. Das jetzt nicht mehr gepflegte Framework von Etsy enthält eine interessante Readme-Datei, in der erklärt wird, wie es funktioniert.
In der Embedded-Software-Welt werden häufig Build-Time-Flags verwendet, z. B. im App-Code selbst ( #define/ #ifdefAnweisungen) und / oder in Konfigurationsdateien für Build-Tools ( makefile's).
Build-Flags können auf ähnliche Weise nicht nur für Features, sondern auch für alle Arten von Code-Refactoring, Migrationen, Debug-Unterstützung usw. verwendet werden. Sie ermöglichen das Festschreiben von teilweisen oder nicht überprüften Änderungen in der Integrationsbranche, ohne den Build zu unterbrechen oder Regressionen in den Funktionen / Projekten zu verursachen, die bereits in der Branche arbeiten. Hervorragend geeignet für die kontinuierliche Integration von Punktkorrekturen neben großen / riskanten / langsamen Fortschrittsänderungen (für die ansonsten ein langlebiger Zweig erforderlich wäre).
Zusätzlich zur Überprüfung des bereits vorhandenen Verzweigungscodes auf Regressionen ist es auch möglich, Fortschritts- / Stabilitätsüberprüfungen des neuen Codes durchzuführen. Dazu müssen die Build-Time-Flags umgeschaltet werden.
Eine Möglichkeit zum Umschalten der Flags besteht darin, in einer separaten Überprüfungspipeline des CI-Systems desselben Zweigs (sofern dies unterstützt wird) ein Patchfile zum Umschalten der Flags zu verwenden, das vor dem Upgrade auf einen separaten Arbeitsbereich angewendet wird bauen. In diesem Arbeitsbereich wird ein anderer Satz von Artefakten erstellt und anschließend überprüft.
Alternativ kann ein langlebiger Feature-Zweig aus dem Hauptintegrationszweig gezogen werden, aber die einzige Änderung in diesem Feature-Zweig wäre das umgeschaltete Flag. Aufgrund dieser winzigen Änderung kann der Feature-Zweig extrem schnell automatisch synchronisiert werden - praktisch wird der Hauptintegrationszweig sehr genau abgeschattet. Eine separate CI-Ausführung auf diesem Zweig würde keine vorläufige Patchdatei mehr benötigen. Es wäre trivial, einen solchen Feature-Zweig auch über einen längeren Zeitraum herumzutragen.
Es kann auch möglich sein, im Hauptintegrationszweig neue Build-Artefakte zu erstellen, die eigentlich nur Klone der vorhandenen Build-Artefakte wären, bei denen die Flags jedoch umgeschaltet sind. Auf diese Weise wären weder das vorläufige Patchfile noch der Feature-Zweig erforderlich, um den neuen Code direkt im Hauptzweig zu verifizieren.