Managing demo and customer features with deployment toggles

The deployment problem

At SI Analytics, technology research and product development ran separately. The business development team needed to demonstrate research features in the existing product before we had agreed when to deliver them to customers. Those features might later become part of the product, so we kept the work in one Git repository and controlled which features each demo or deployment exposed.

Developers could not assist with every demonstration. Business development needed instructions for turning features on or off, or automatic selection based on the deployment environment, such as its URL.

Features requested by major customers also had to remain hidden in public demonstrations. As those rules accumulated, feature activation became business logic that needed one place to manage it.

Design and adoption

I designed the toggle system, wrote a usage guide, and ran short training sessions for colleagues. I continued reviewing the code as the team adopted it.

Separating demo settings from deployment restrictions

I proposed managing the toggles in YAML because the company already used it for many configuration files. To prepare a demo, business development followed a guide to locate the YAML file inside the Docker container and edit the feature settings.

The editable file was one input to the decision. Two other mechanisms constrained which features could be enabled:

• Branch or tag naming patterns could disable selected features completely for a particular release.
• URL-based conditions disabled features that were not allowed in that deployment, even if business development changed the YAML settings.

This separated the features requested for a demonstration from the restrictions on the release and deployment. Editing a demo configuration could not override those restrictions.

A shared React interface

I added a shared React hook at the main feature-toggle points. Components could use that hook without each having to interpret the configuration and deployment conditions.

Keeping business logic understandable

The surrounding business logic still needed clear module boundaries. In the guide and training sessions, I covered how toggle checks became harder to follow when they mixed levels of abstraction. I used code reviews to keep those checks consistent as colleagues added them.

What changed in demo preparation

Before this change, demo preparation involved message exchanges followed by developer intervention to deactivate features. Manual mistakes repeatedly caused bugs.

Once the configuration and guide were in use, the team could prepare demos without asking developers to change the feature settings.