Building a Show New Remote Variables Feature with Feature Flags

When building DevCycle we wanted to create a show new remote variables feature that would replace existing functionality that we had in our app. Our original functionality wasn’t well designed and we created a cleaner and newer UI that our customers would love.

What changes we made to our feature

The previous look of our feature felt like an Excel sheet where you could modify specific cells. It was a cumbersome area where it was easy to accidentally end up modifying the wrong field, and if you had more than three variations and variables (a 9 by 9 grid), it became hard to read.

Our new version looks cleaner and it’s easy to see the type of data that you have and that you would be modifying or editing. Now everything pops up in a self-contained modal window. There are also more prompts so in the event that you’re deleting something you have to go through a prompt that confirms your deletion. This means a user is no longer at risk of accidentally deleting their work. 

Using feature flags to create the new feature

In order to create a new component, we feature-flagged the old component and introduced the new version behind a feature flag. As we went through the development process we were able to test in across the local, staging and production environments. 

This functionality relates to the part of the application where a user can define new variables and variations that they want to serve their customers. This includes everything from adding in new variables, modifying existing ones, and being able to delete variations. In order to do this, we had a popup where a user could easily edit fields. We also introduced the ability to have JSON variables. This meant we had multiple feature flags happening at once which allowed us to test things independently without being overwhelmed.

When deciding how to build this new feature we broke it down into four distinct pieces of functionality that we were aiming to achieve. The first was wanting a user to be able to see all the data in a clean table format. From there we moved on to being able to add in new variables and variations. To do this we created modals for each variable and wrote them into our feature flag. Within those larger modals, we had a second feature flag for adding in JSON variables and making sure that when a user is entering JSON we want it to be valid so our API wouldn’t reject it.

Having all the validation in place was the hardest part of building the JSON variables feature flag. We had to ensure when we enabled the JSON variables feature flag we didn’t accidentally go live with the new remote variables since we had only completed the read functionality but not the creation, updating or deletion of variables and variations. At this point, since we weren’t code complete with our new remote variables functionality, which meant that turning on this feature flag was a big moment of truth. 

Luckily, we didn’t break anything so we were able to work on those two pieces in parallel while ensuring the rest of the app’s functionality didn’t change to the end-user. This means an end-user would never run into a situation where they were adding something but weren’t able to edit their variables and variations.

When we were ready to go live we simply turned the feature flag on and enabled it for everyone. Since this new feature was a complete replacement of an older one we were able to delete the old feature and code within it once our new version was running smoothly.

‍
Learning from this process

Creating this feature provided our team with a lot of learnings. If we were to do this process again we would create parent feature flags around the entire feature. From there we would have feature flags within the parent feature to be treated as variables in different variations. For example, if we had three components that we were working on within a feature we would create variables. 

We would then have four variables, one for the parent and three for the sub-variables. Going back to the example with remote variables we had read, add, edit and delete we would wrap the entire thing in a feature flag. There would be one variable to show you a remote variable and then three additional features which would show add variables and variations, show edit variables and variation, and show delete variables and variations.

This way, with one feature flag we could set up a different combination of variations to promote our code through the different environments to allow for testing just by changing the value in one variation to turn on that feature flag.

This means that once we’re done adding the ability to add a variable or variation we could change the variable value for that variation to be true. Then it could go live to our internal testers and users. Once we’re confident it’s ready to go live to everyone we could simply turn it on for everyone. With this method, each variable is essentially a small feature flag within the bigger feature flag.

What it would be like building without feature flags

Building this without feature flags would be scary as an engineer since one of the core functionalities of feature management is defining variables and variations. With feature flags, if there are bugs we can just turn off the flag to disable it then go back to the lower environment to resolve the bug. Without feature flags, we would have to roll back the entire app deployment which would be at least half a day's work.

Start using feature flags

Feature flags are a tool that makes building new features easier. They help minimize risk and allow your developers to work more efficiently. Get started using feature flags with a 14-day free trial of DevCycle.