Our teams practice the Trunk Based Development approach - new code is immediately added to the master branch, third-party branches live for a maximum of several days. And so that commits do not interfere with each other, developers use Feature Flags - switches in the code that start and stop the work of its components.
Consider a typical development iteration: planning, specifying requirements, creating tasks in the tracker, development. As the tasks are ready, they are deployed in the test environment for testing, the release branch stabilizes. Then release finally comes and the team can finally get real feedback from users.
If you are trying to shorten Time-to-Market, this is too long. The sooner you get feedback from users, the sooner you fix mistakes, the less time you spend on bad ideas, the more resources you can devote to successful ideas.
In order for updates to reach the sale faster, one iteration should include one feature. That is why it is necessary to shorten the life of the branches.
Long-lived branch problems
Conflicts between commits (Merge hell). Delaying the release, integration with an external system, and other external factors can render the count inoperative.
Difficulties with code sharing. Other team members may need code from the new branch if the features depend on each other. We have to start another branch just for the sake of accessing this code.
Test environment problems. If there is only one test server, and there are many feature branches, it will not work to test tasks in parallel.
It's hard to roll back changes. Problems after a release are common, and if a new feature branch starts to fail, developers have to choose between hotfix and reverse, go into the source code, and re-upload the solution.
How Trunk Based Development Solves These Problems
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 , .
The flags are changed through the portal, which sends an integration message to the bus when the status is updated. The Config Updater component updates the flag values โโin FF-ConfigMap via the K8S API.
Finally about testing
The question arises, how to test a product with feature flags? At first glance, flags complicate this process - if there are a lot of switches, then the number of all possible states increases dramatically.
But flags do not always depend on each other. Therefore, we are testing two limiting cases for the release: 1) all new flags are off and 2) all flags are on.
Practice shows that this is usually enough.