The 6 Types of Feature Flags You’ll Meet at Optimizely: Operational

Tl;dr

🚩 How do we use Operational Flags at Optimizely? Making dynamic changes to a feature without a code deploy.
🔒 Access Level?  Only Optinauts that built the feature.
😬 Risk Level? Medium-High.
👩‍💻 Tests? QA Environment.
⏰ Lifetime? Permanent until feature deprecated.

Operational feature flags are flags that control configurations for an application, such as controlling a front end element in your application (Optimizely’s own Asa Schachar demos this here by changing the height of an astronaut image on an app). These are usually done through the flags feature variable, which allows you to dynamically change values in production without deploying code.  

How do we use Operational Feature Flags at Optimizely?

Operational feature flags are the second most widely used feature flags at Optimizely (Feature Rollouts being the most widely used). Here are some of the ways teams at Optimizely use operational feature flags:

• Design Team uses an operational flag to dynamically change the location of where our banner image is sourced from. This allows them to make changes to the banner without requiring a code deployment. 
• Developers use an operational flag to set a max number of calls to a certain service. This gives them the ability to make changes to the service dynamically in production.
• Documentation team uses an operational flag to source where the article links are coming from. One of the benefits of doing this is they can stage articles reflecting new products, and once the product releases, switch to the new article without changing code. 
• Infrastructure teams use an operational flag to change what algorithms are currently being used. This allows them to tweak production behavior without having to do a code change.

By dynamically allowing our teams to make changes in production without having to wait for a code deployment, we increase the velocity in pushing features to our customers. We also remove the overhead of having to make code changes for our non-technical teams. 

An example usage of an Operational Feature flag controlling some operational aspects using feature variables.

Who is allowed to make changes to the Operational Feature Flag?

Since the operational feature flag makes changes to a feature in production rather than introducing a new feature, we strongly enforce that no one, outside of the development team that implemented the operational feature flag or the design/documentation teams that utilize the feature flag, can make changes. Since these changes are not a simple off or on, but rather an entire behavior change, we have to be very sensitive over the exact flow of implementation. For example, an operational feature flag may gate how many machines are to be spun up for a certain job. Incorrectly changing this number to too low may cause the pool of machines to become overwhelmed and cause critical failure in the infrastructure. Optimizely’s Change History log is very useful to our operational feature flags because it allows the developers to review what has been done historically in the past, and to allow us to see what the state of our code is currently. 

What is the risk level for using an Operational Feature Flag?

Operational feature flags tend to be a medium to high risk feature flag depending on what we are implementing since they are changing the behavior of a feature. For a new feature, if it doesn’t quite work, you can roll back. However, if the behavior of a feature isn’t correct, in some instances, the change in behavior has already made an impact on your system and those changes cannot be rolled back. That is why before we implement changes through our operational feature flag, these risks need to be understood, and a strategy to mitigate each must be planned before we switch anything on or off.

How does Optimizely test its deployment of Operational Feature Flags?

Operational feature flags are tested in a QA environment that can be destroyed and brought back without issue. We test our change, and then test rolling back that change and then check to see if our assumptions on behavior is correct. Can we rollback? If not, and something breaks, what is our strategy?

When does Optimizely remove its Operational Feature Flags?

Operational feature flags are long term flags and tend to never be removed since they are responsible for dynamically controlling a part of our application. However, if the feature it is responsible for has been deprecated, the team that deprecates that feature will remove all the code associated with the feature including the operational feature flag.

This is the part of a series that will dive more into the different feature flag types we have here at Optimizely, as well as the engineering teams that implement them. See you next time as we dive in deeper on Permissions feature flag type.

If you’re looking to get started with or scale feature flags, check out our free solution: Optimizely Rollouts! 

Are you using operational feature flags at your company? I’d love to hear about your experience! Twitter, LinkedIn