Feature Flags in Rails: Get Started Quickly and Easily

The following is a guest blog post written by Taurai Mutimutema.

Creating dynamic applications with Rails (or any language + framework combo) has become more of an ongoing process than a single event. Users often require the best experience when using apps and this often means that a team of developers ought to continue improving their code on a regular basis. Feature flags in Rails are the way to deliver new functionality and well, features, to the users without risking the user experience factor.

There are various reasons why using feature flags has become the norm these days, but you should be clear on when and how to implement them in your feature deployment scenario. This article will help you understand the benefits of using feature flags. We’ll also show you an easy way to have them ready and waiting when using Rails. You may as well get acquainted now since they seem to be here to stay.

Here is a brief outline of what you'll learn in this post:

• The Rationale Behind Feature Flags

• When You Should Use Feature Flags

• Best Ways to Use Feature Flags in Rails

Let's dig in.

Let’s take a simple web application built on Rails as a test case. Before any underlying code (even markup) starts getting complex, it is at first sufficient to have nested "if" statements to suggest different states or dimensions depending on the access environment. Changing the width of the app when the user changes a device can seem like a big deal to the user. However, the if logic maximizes the experience of every user regardless of their access device.

Now imagine a scenario where that same above code grows beyond a handful of classes and functions. Things get more interesting. Even when the device has little effect on user experience, rolling out new features would require tests and more control structures. For one, you could release (or remove comments from) new lines of code that have an adverse effect on the entire program.

It then makes sense to have new features stand apart from the main code and only get called when certain conditions are met. These conditions can be a marketing test decision to try a feature on only a small segment of the total number of users through A/B testing. Something like having a feature go live based on location also calls for feature flags. Think about how Netflix manages to place an invisible access barrier based on where you’re streaming from.

Such a setup on the back end allows for users to access the software differently based on factors like location, the device used, the season and other criteria that determine deployment in your organization. The risk (and hard work) of having to alter code every time you need to roll out a feature is averted completely.

Let’s look at the technical determination for the need to have feature flags. As mentioned above, you could go without them if your code is still maybe a single page in total length. However, they do become somewhat of a prerequisite when your lines of code show no stop in the near future. It is often a good idea to weigh the need for feature flags before going forward with any. Look beyond the fact that your code is getting more complex as more lines pile up. A special request from a user can give rise to the creation of feature flags.

The most common reason for having feature flags is to have controlled releases of new features to your users. In addition to this, you could also have feature flags on the ready as circuit breakers for when the worst events happen. Wisdom would have it that right when you start working on a sizable update to your program, some feature flag is created and run such that the developers have a different view of the overall system based on their access credentials. Changes made under such a setup would not stop the rest of the users from enjoying normal access and functionalities.

There are several ways you can start implementing flags in your code. The best way is often not including (activating) the new code into the already functioning source. Before demonstrating some simple implementations, it would make sense to differentiate between feature flags and forks in version control. Just the idea of taking the code out of functional state can bring up ideas about making a backup and adding features therein. That is not what feature flags are all about.

If you were looking to make a different version of some software, forking to a different but basically identical concept and then growing it would be the best way to go. In the event that the fork successfully allows you to test changes, it would basically replace the main. To avoid confusion, feature flags will still be part of the original (we don’t have to fork out of the foundation). However, they are selectively accessible. Changes are tested without the need for an entirely different project running under some subdomain.

Developers often find themselves starting a few lines and thinking “Hey, I’m not the first person pressed with this issue, so there must be a gem for this.” And yes, there are options you could explore to start taking advantage of feature flags. Better yet, you could have them accessible on a dashboard as is the case with CloudBees Feature Management.

While a comprehensive tutorial will be handed down as part of the documentation, we promised to show how easy you could set it up in Ruby. With a few lines of code, you will be able to test out new features as you toggle (on and off) conditions.

Disclaimer: This is the standard code from CloudBees Feature Management when adding the Ruby SDK. You usually need to have an account to see it, so here is a sneak peek. A free account gets you full access.

# Add the CloudBees Feature Management SDK to your application
$ gem install rox-rollout


After this command successfully adds the gem to your project, you then add the Ruby SDK by adding the following code into yours.


# import CloudBees SDK
require 'rox/server/rox_server'

# Create Roxflags in the Flags container class
class Flags
attr_accessor :enableTutorial, :titleColors
def initialize
# Define the feature flags
@enableTutorial = Rox::Server::RoxFlag.new(false)
@titleColors = Rox::Server::RoxVariant.new('red', ['red', 'blue', 'green'])
end
end

flags = Flags.new

# Register the flags container with CloudBees Feature Management
Rox::Server::RoxServer.register('', flags)

# Setup the CloudBees Feature Management environment key
Rox::Server::RoxServer.setup("<CLOUDBEES-ENV-KEY>").join

# Boolean flag example
puts "enableTutorial is #{flags.enableTutorial.enabled? ? "enabled" : "disabled"}"

# Multivariate flag example
puts "titleColors is #{flags.titleColors.value}"

And that’s it. After you have defined your flags, they immediately become available for experimentation in the CloudBees Feature Management dashboard. Cool to note is that in the same account, you can have multiple apps and their respective flags configured.

At this point, you can create new experiments and run them based on deployment rules. Such a rule could mean that a target audience becomes less technical and more practical. See the image below for a screen capture of the process in the CloudBees Feature Management interface.

With the guidance provided here, it should now be easy for you to create feature flags for Rails applications. Not only that, but it should also be relatively easier to decide when not to use them. You can explain the detailed requirement in appraisal meetings, all in such a way that other departments become keen on coming on board. The CloudBees Feature Management gem, along with the dashboard, makes it almost effortless. Try it out for yourself.

Taurai Mutimutema is a systems analyst with a knack for writing, which was probably sparked by the need to document technical processes during code and implementation sessions. He enjoys learning new technology, and talks about tech even more than he writes.