Using the Optimizely IntelliJ Plugin for Feature Development

This made my development flow hard to maintain because of all the context switching between application and IDE. It is also error prone with no way to test my configuration or audience other than to develop and run the project.

So, I wrote an IntelliJ plugin for Optimizely, which helps you to manage, and use feature flags and experiments within the IDE. 

If you aren’t familiar with feature gating and experimentation, adopting these useful tools will allow you mitigate the risk of launching new features from deploying to delighting customers. If you are already familiar with using Optimizely, great! This will show you how to easily integrate this helpful plugin with your Optimizely workflows.

The IDE plugin: 

• Shows the feature flag or experiment key by auto-complete
• Accesses all of Optimizely config options via keyboard shortcuts
• Insert attribute, event, and variable/variation keys available from the keyboard
• Jumps straight to a feature or experiment edit page and add and consume variables easily
• Shows a debug dialog that allows you to debug your configuration and complex audience combinations

Let’s go through a scenario on how you might use Optimizely and the IntelliJ PlugIn. The Optimizely IntelliJ plugin actually works with all Jetbrains based IDEs. It supports auto-complete for Go, Java, Kotlin and Python.

Before using the plugin, you’ll need to install the Optimizely SDK in your application. You can go to the developer documentation, pick your language and SDK to get started.

You will also want to install the Optimizely Plugin, which is available by going to Preferences > Plugin. Optimizely plugin will be in your list of marketplace plugins that you can install. Simply click on install and install the plugin.

Next, we will planout what features we want to gate behind a feature flag and walk through an example of creating a feature flag and implementing it in the IDE. In the example below we are going to create a feature flag for a new coupon popup for our Android project. We can gate this new coupon feature using a feature flag. First, we will create the feature, then create an audience, in this case for New York and California users, and then test it in the debug dialog. After that is all setup, we can add the code to our project. 

After creating the feature flag and an audience (for instance, you want to target by location, which you will pickup in the HTTP Header or via mobile location), we will switch over to the IDE.

The driving configuration key is the SDK key for the Optimizely environment we are using. Hit option/alt – o and s and then the SDK key entry screen will pop up.

From there if you are using Go, Java, Kotlin or Python, you can use autocomplete while typing Optimizely SDK methods like isFeatureEnabled, getFeatureVariableString, and activate. If you are using a different language or don’t want to use autocomplete, you can use option-o e (for experiment) option-o f (for feature) option-o v lists the last variables or variations depending on which feature or experiment you picked last.

Here’s an example of ruby which does not have autocomplete yet:

And a Java example also using activate with autocomplete:

Jumping back to our Java example, we want to see if there is a feature key show_coupon, the name we gave to our coupon feature, and if it is true, then show the coupon. Below is a snapshot of the autocomplete with “show_coupon.”

First, let’s check if the coupon is enabled. If it is, then use the feature key by passing it to our Android activity to show the coupon. We can pass it as extra data in the intent as shown below.

You can also easily access feature variables by type with auto complete. Below is a gif of getting the message and discount.

In the gif, the getFeatureVariableString function will return only variables of type string. It relies on the fact that the first variable is a quoted string of the feature key.

Great! We also want to be able to react if the feature changes. So, we will add a notification handler and respond by resetting that variable.

Ok, now we have a feature wrapped in a feature flag that is updated whenever the feature flag changes. But, how about if we want to add an audience so that we can roll out the feature to certain audiences?

The next thing we would do is create our audience in Optimizely.

So, go to the menu, look under Jump To and jump to the show_coupon edit page.

Create an audience.

In this case, we created an audience for NY or CA only. Next, we can use the OptimizelyPlugin to test and add our audience.

Ok, so we just did isFeatureEnabled for my show_coupon and we can see that there was an audience and we were not in it. Now, let’s add an attribute and rerun.

Ah, now we added a location and if it is CA or NY, we will show the coupon. We can change the audience later to be none or something else if we want to increase or decrease the number of customers exposed to the feature. The debug dialog can be really useful when you have very complex audiences and you want to verify how they will work.

Now, we add the audience portion so that we can rollout. We might want to take into account different attributes as well, such as age or some other demographic.

And maybe add any other demographics we might want such as X or Y.

Finally, we want to make sure that we include these attributes in our feature calls. Right now, isFeatureEnabled is where it is most useful (it is used to determine if you are part of a rollout or not) unless your feature is part of an experiment (in which case you can get non-default values for a feature that is on). But, with the addition of targeted features rollouts, you will be able to get different feature variables values based on whether you are targeted or not. So, let’s make sure and add those attributes to all our calls.

So, we have walked through adding a new feature and wrapping it in a feature flag using the Optimizely plugin. The plugin is really useful for initial design and development, however, I would advocate refactoring your code so that your feature flags and conditions are behind a wrapper when you push to production. That way, in the future, you can easily swap out feature names, or deprecate a feature and always return true.

I can’t stress enough how useful feature flagging and experimentation can be for product development. They are really invaluable if you want to advance your UI and feature set quickly and confidently. 

I hope that people find this plugin helpful for creating a reliable well tested experiment and feature environment. We will adapt as we get feedback from engineers, please send along any feedback you have! You can give feedback through the PlugIn review section or open an issue in the github repository.

If you are interested in getting started with progressive delivery, you can sign-up for a free Optimizely Rollouts account.