Branching by Abstraction — Feature Toggles in OutSystems
I recently came across a challenge of how we are going to manage concurrent releases given limited environments. Imagine that there’s development ongoing for Release A and while development is still on-going, there will be new features added for Release B.
Typically, the solution for this in software development is branching. Branching will provide an isolated source code that developers can work separately for both releases. While this often works, the cost of merging gets huge and often impacts the quality of the release (a.k.a as merge hell).
While there’s really a solid use case that branching can really be helpful — if a feature to develop is disruptive and you don’t want the development to pause (e.g. feature that will involve refactoring), for this reason, OutSystems is exploring the idea of having such a feature.
… I hope it’s as easy as this. New environment requires both time and money. It will also not be sustainable to maintain a new environment per release.
Introducing… a way to Branch by abstraction — “Feature toggles” (a.k.a feature flags).
Feature Toggles (often also referred to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it’s important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practices and appropriate tools to manage our toggle configuration, but we should also aim to constrain the number of toggles in our system.
Advantages:
- Less complex merging — you are working the same on the code that will be release
- Ability to turn off broken feature during runtime when it’s not working
- Ability to release with unfinished work
- On a multi-tenant setup or by using roles, it gives the ability to enable a feature for only one group of users
Disadvantages:
- Will require an understanding of the flag concept to the whole group
- If not careful, it may leak some codes that are not supposed to be released
- Code gets thick and sometimes code duplication is needed
- Can increase technical debt because floating code that gets left out
It was shown here that features are bound to toggles which enables the flexibility to turn off broken features instead of delaying things and wait for the remaining feature to finish which business won’t like.
So how do you implement feature toggles in OutSystems? Let’s start simple — use boolean Site Properties to act as a flag and use Service Center to toggle it on and off. I also like the fact that Site Properties are now integrated with Lifetime which enables the publisher to specify immediately if that feature is available for a specific environment.
For large projects, it’ll be better to create another module to manage all the site properties. For multi-tenant, site property might not be enough; you will be needing a table to manage the association of TenantId and the flags.
Site properties work on both client-side and server-side, some caching mechanisms may come into play to avoid lots of server calls (e.g cache the value of the site property upon login through session or client variables).
One thing to highlight in reactive and mobile, server actions that are being used by screens needs to be protected as they will be exposed by REST API and we don’t want unwanted codes to be accessible.
Feature toggle is not a silver bullet for lack of environment rather it should be considered a solution to improve development operation and able to do continuous delivery. Speed should still come with quality, integrate with different DevOps practices to get both.
