Bring unfinished work into production: Release Toggles to the rescue!

Hi all, how many of you have faced this problem?

"The sprint is done, the product owner has accepted everything. The changes go for user acceptance but only part of the functionality gets approved. You want to bring what is approved into production but the other functionality should not be made available. What to do? "

More often than not, we solve this problem by using site properties. I propose a different solution and have made a Forge component available to exemplify it. It is called Release Toggles.

So what are the disadvantages of using site properties for the purpose of revealing or hiding functionality in runtime?

- release toggle site properties are shown in service center along with all other configuration site properties. This makes it difficult to distinguish one from the other unless we put some effort in naming release toggle site properties in a clear and consistent manner.

- As release toggle site properties are spread throughout a multitude of modules, it is difficult to have an overview of all of them. (Yes, it is possible to query the outsystems tables and obtain this overview, but, once again, we are dependent on how well and consistently we name them)

- By having a release toggle represented by a single site property we are unable to associate extra (and useful) information with it. You can think of the title and description of the user story that explains the purpose of the feature behind the toggle and all its details, the team that is responsible for its implementation, the number of the version in which the functionality is expected to be released, etc.

- Frequently the code changes related with a given feature are spread throughout multiple modules. Ideally we only have one single release toggle site property in an end-user module but that is not always feasible. Whenever the same release toggle site property is spread throughout different modules, we need to be extra careful when updating its value. Before we know it, they are out of synch.

- In some cases, a release toggle is not simply on or off. It can be on for a couple of users and off for others. Alternatively, it can be only be on if other release toggles are also on. In sum, the status of a release toggle depends on contextual information. This is not possible to achieve by relying simply on site properties.

So what is the alternative? What do I propose?

I would say it is important to have an overview of all release toggles. That each release toggle should be accompanied with detailed information about the feature behind it, who is responsible for it, etc. I would also say that turning a feature on or off should be possible by sliding a single toggle, irrespectively on whether the implementation of that feature resulted in changes to a single module or to multiple modules. Finally, I would say that it should be easy to remove a release toggle. Release toggles introduce complexity. They should be removed the moment the feature is running properly in production.

The Release Toggles component has been built taking all of these considerations into account. It has helped me and others already in tackling this problem. Maybe it can also help you.

Let me know what you think. Do you have other ideas on how to tackle the problem mentioned? I would like to hear.


Hi Pedro,

Interesting component! I'm going to take a look at it for sure.

Hi Pedro,

Seems an interesting component.

When I need something like this I will take a look to this component.

We mostly had complete menu functions that would be enabled for releases, kind of solved it by using a serverlevel in the menus, 1 would be dev, 4 prod and all in between. By setting the menu to serverlevel 2 it would be shown on dev and test but not on acc and prod. When stuff would be approved for prod, we set the level to 4. This is all on a mobile application which has a load of menu screens for getting to functionality. It would go wrong sometimes but it works nicely. Also our situation was complex with a big number of end production servers (100+) which would be impossible to manually set right, I think with a more normal street with just a small number of end prod servers your solution would be much more in control.

Hi Wim, the solution you describe sounds interesting. I was wondering how the menu level was set. Did you use site properties? Added an attribute to the MenuItem static entity? Do you need to redeploy one or more applications whenever changing the menu level?

With respect to whether or not to apply the ReleaseToggles component in the case of 100+ front-end servers, I don't see any problem in doing so. After all, the status of a release toggle is kept in the database (I'm assuming in here that all application servers share the same database). In addition, because the status of the release toggles is also cached in the front-end servers, you should not see any performance penalty.

Thanks Kilian and thanks Nelson. Let me know if you encounter any problems while using it or if you have any suggestions. 


The menulevel was indeed added to the static entiy and a site property was there to indicate the serverlevel. Set to prod as default, changed in servicecenter for dev, tst and acc environment.

All the app servers on prod level are situated in the stores and have their own db running so they are able to keep on working even if the internet connection to the central servers is disrupted. so changing the settings for the releasetoggles component will mean a script to update the db or manually go to 1000 servers which isn't really a good option :-)