Unsere Teams praktizieren den Trunk Based Development-Ansatz - neuer Code wird sofort zur Hauptniederlassung hinzugefügt, Zweige von Drittanbietern leben maximal mehrere Tage. Damit sich Commits nicht gegenseitig stören, verwenden Entwickler Feature-Flags - Schalter im Code, die die Arbeit ihrer Komponenten starten und stoppen.
Stellen Sie sich eine typische Entwicklungsiteration vor: Planen, Festlegen von Anforderungen, Erstellen von Aufgaben im Tracker, Entwickeln. Sobald die Aufgaben fertig sind, werden sie zum Testen in der Testumgebung bereitgestellt, und der Release-Zweig stabilisiert sich. Dann kommt endlich die Veröffentlichung und das Team kann endlich echtes Feedback von den Benutzern erhalten.
Wenn Sie die Markteinführungszeit verkürzen möchten, ist das zu lang. Je schneller Sie Feedback von Benutzern erhalten, je schneller Sie Fehler beheben, desto weniger Zeit Sie für schlechte Ideen aufwenden, desto mehr Ressourcen können Sie für erfolgreiche Ideen verwenden.
Damit Updates schneller zum Verkauf gelangen, sollte eine Iteration eine Funktion enthalten. Deshalb ist es notwendig, die Lebensdauer der Zweige zu verkürzen.
Langlebige Zweigprobleme
Konflikte zwischen Commits (Merge Hell). Eine Verzögerung der Freigabe, die Integration in ein externes System und andere externe Faktoren können dazu führen, dass die Zählung nicht mehr funktioniert.
Schwierigkeiten bei der Codefreigabe. Andere Teammitglieder benötigen möglicherweise Code aus dem neuen Zweig, wenn die Funktionen voneinander abhängen. Wir müssen einen weiteren Zweig starten, um auf diesen Code zugreifen zu können.
Probleme mit der Testumgebung. Wenn es nur einen Testserver gibt und es viele Feature-Zweige gibt, funktioniert es nicht, Aufgaben parallel zu testen.
Es ist schwierig, Änderungen rückgängig zu machen. Probleme nach einer Veröffentlichung treten häufig auf. Wenn ein neuer Feature-Zweig fehlschlägt, müssen Entwickler zwischen Hotfix und Reverse wählen, in den Quellcode wechseln und die Lösung erneut hochladen.
Wie Trunk Based Development diese Probleme löst
Trunk Based Development ( . trunk – « ») – . Gitflow, TBD master. feature- , .
Trunk Based Development , trunk. , , , -. .
trunk -. , . trunk , .
, - , ? Feature Flags.
Feature Flags
, IF-, . – , . : , - . – , .
(toggle router), . , , . ( ), (, , , ..).
Feature Flags
- , :
(release toggles): , , . .
(experiment toggles): A/B , . % , .
(permission toggles): . , .
(ops toggles): . , – , .
### Feature Flags
– .
– - , .
– TBD , .
: LaunchDarkly, Bullet-Train, Unleash. - , - . , .
Open source : Moggles, Esquilo. , , . , , .
: , . , . .
Feature Flags Portal (FF-Portal): Web + REST API . .
Feature Flags Storage (FF-Storage): .
Kubernetes ConfigMap (FF-configmap): k8s ConfigMap , , FF-Storage . FF-Portal FF-configmap.
Microservice (MS): , FF-configmap . FF-configmap, .
FF-ConfigMap, Pod- . ConfigMap, k8s , .
Die Flags werden über das Portal geändert, das eine Integrationsnachricht an den Bus sendet, wenn der Status aktualisiert wird. Die Config Updater-Komponente aktualisiert die Flag-Werte in FF-ConfigMap über die K8S-API.
Zum Schluss noch zum Testen
Es stellt sich die Frage, wie ein Produkt mit Feature-Flags getestet werden kann. Auf den ersten Blick erschweren Flags diesen Prozess - wenn es viele Schalter gibt, steigt die Anzahl aller möglichen Zustände dramatisch an.
Aber Flaggen hängen nicht immer voneinander ab. Daher testen wir zwei Grenzfälle für die Veröffentlichung: 1) Alle neuen Flags sind deaktiviert und 2) Alle Flags sind aktiviert.
Die Praxis zeigt, dass dies normalerweise ausreicht.