By now it is well known that feature branch based development is problematic (because of merge conflicts) and
trunk based development with feature toggles is a good alternative. But the simple idea of a feature toggle can
be extended in several ways e.g. to allow much more fine grained control when and where a feature becomes
visible or to verify the new code behind a feature toggle before the toggle is switched. Join this session to learn
new patterns which ensure that everything works when a new feature is finally activated in production.
Target Audience: Architects, Developers, Technical Project Leader, Testers
Prerequisites: none (well, I expect some programming background ;)
You will learn
Participants will learn several not wildly known extension to the simple idea of a feature toggle, which can be easily implemented and enable delivering new features with very high quality (not only functional correctness but also robustness and performance) without costing much compared to other QA activities.
Extended AbstractThe development department of our company is practicing trunk based development with "feature toggles on steroids" since several years now. This sessions is about sharing our experience as well as several patterns for painlessly rolling out new features on our SaaS-Platform broadmail, which are:
• Our system comprises several hosts and we can specify for each feature toggle if it should be active on all hosts or just on selected hosts (e.g. test or stand by hosts).
• We have several customers organized in a hierarchy tree. Our future toggles are bound to this inheritance hierarchy so that features can be enabled for all customers (in the root node of the hierarchy) or just for beta test or special customers without affecting other customers.
• We have established a pattern where a new feature gets two feature toggles: useFeatureX and verifyFeatureX. This allows the four combinations:
1.) use old code,
2.) use old code *and* verify new code asynchronously (i.e. without the user noticing)
3.) use new code *and* verify against old code (just to make sure that the new code really works as expected for an extended range of time)
4.) use new code
This patterns enabled us to verify the correctness as well as the performance of new code in the production environment during development before a new feature was actually turned on. (This pattern is also known as "Verify Branch By Abstraction")
• We have extended our test framework (based on JUnit) so that a single test can easily be executed several times with different combinations of feature toggles turned on or off.
The patterns above have helped us in the past to deliver new features with very high quality, but unfortunately those patterns are not widely known. Therefore I would like to spread the knowledge by giving this presentation.
I plan to start the presentation with a short recap of how trunk based development with feature toggles works (also known as "Branch By Abstraction"). Then I would show the different patterns using our SaaS-System as a real world example. I would also like to show some Java code snippets so that listeners will have a good idea how they could implement the patterns them self.