Hello everyone,
We currently have an application running in production while simultaneously developing additional functionality. Before releasing new functionality to all customers, we will release it to a small group of users as a pilot release for testing.
So far, we have been using Site Properties to control access to these features. However, as the number of Site Properties has gradually increased, they have become difficult to manage and maintain. So looking for an alternative approach and came across the Plugin Feature Toggle.
https://www.outsystems.com/forge/component-overview/9664/feature-toggle-management-o11
We would appreciate your expert advice on this. Is there any other plugin or approach that would better suit this requirement? Also, are there any limitations or considerations we should be aware of when using Feature Toggles for this type of pilot release?
Any recommendations or best practices would be greatly appreciated.
Thanks,
Hello @Jayakumar R,
You can achieve the desired behavior using the relevant System Entities.
Basically, you can use them to list all the Site Properties in the system along with the corresponding module name, and expose them through a single screen with a restricted Role. From there, users with the appropriate access can modify the Site Properties Property_Value based on the requirements for each environment.
This would give you a centralized place to manage the Site Properties instead of having to manage them individually across different modules.
Dear Sherif,
Thanks for your reply.
Yes, we can list all the Site Property values on a single screen and provide an option to switch or update the values. However, I believe OutSystems does not recommend modifying Site Property values directly through database queries or through an OutSystems CRED Actions , as there may be internal processes involved, such as cache invalidation and synchronization.
Currently, we have more than 2000 Site Properties across multiple applications with different User Providers.
Our goal is to have a controlled feature management . For example, if any service goes down or causes an issue, we should be able to disable the related feature immediately. Once the service is restored, we can enable the feature for a small group of users first for validation. After confirming that everything is working as expected, we can enable it for all users.
Totally agree with you. But a feature toggle is basically an additional condition in the application logic that determines whether a particular functionality should continue executing or not. For example, if the feature is enabled for the current user, the flow continues; otherwise, the functionality is skipped or handled differently.
Regarding cache invalidation and synchronization, I agree that this is something we should consider carefully. However, if the Feature Toggle Management component is ultimately managing its configuration in a way that relies on Site Properties, then the same considerations around cache invalidation would apply. OutSystems Site Properties are cached, and changing their values at runtime triggers cache invalidation.
That being said, I honestly haven't tried the component myself, so I cannot confirm how it handles this internally. Therefore, I would suggest checking the detailed documentation and, more importantly, how the component is implemented in the background particularly how it stores the toggle values, handles caching, and synchronizes changes across environments. Once you have that information, you can make a better decision on whether it is suitable for your requirement.
Hi @Jayakumar R ,
The plugin you shared provides everything required for your use case and is well documented.
If you don’t need an infrastructure-wide solution, a simpler alternative would be to create a dedicated role for the feature and assign it only to the pilot users. OutSystems documents this approach here: Feature Toggle Management .
Dear Mihai,
Thanks for your response.
We are also planning to proceed with the Feature Toggle approach. Before finalizing it, we would like to explore whether there are any better options available, considering that our applications use different User Providers and include Traditional Web, Reactive Web, and Mobile applications.
A role-based approach may not be suitable for us, as we plan to use feature toggles for many features. Creating separate roles, assigning them to selected users for testing, and later assigning or revoking them for all customers would be difficult to manage.
Also, since we have different User Providers, role management would need to be handled in different interface separately.
we are looking more centralized and simple approach to manage features.
The feature toggle concept is the way to go, of course you could create it yourself, but the mentioned available components are great. Just be mindful that if you install the feature toggle management app in production it costs a considerable amount of AO's.
You don't need to install it in production, you could also do it in acceptance, even for the endpoints in production. This is not ideal, as you generate a dependency between acceptance and production. With a bit of refactoring you can overcome that as well, where you just sync from acceptance to production the feature toggle status.
Out of curiosity,
the feature toggles can say of a certain feature if it is in canary / beta / alpha / ..., but how does the software decide if any given user can then make use of it ?
Does each user have a general switch attached 'i am a canary tester' or would it be a per user / per feature switch 'for feature X, I'm on Canary, for feature Y I'm on Beta, for all others, I'm on Alpha'
Dorine
The feature toggle management has no such capabilities to my knowledge. Its on or off for all users. Not an A/B testing tool. You would need to extend the tool to have this functionallity. We did this in the past to toggle per users of a retail store of a retail chain.
yes, and that is the original ask if i read it right, some ussers get the new feature.