Feature Flags in Rails: Get Started Quickly and Easily

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 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 to 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.

The Rationale Behind Feature Flags

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 the same 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 the location from which you’re streaming.

Such a setup on the backend allows 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.

When You Should Use Feature Flags

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 a single page in total length. However, they do become somewhat of a prerequisite as your lines of code grow. It is often a good idea to weigh the need for feature flags before going forward with using them. 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.

Best Ways to Use Feature Flags in Rails

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 codebase. 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 its functional state can bring up ideas about making a backup and adding features therein. That is not what feature flags are all about.

Feature Flags Versus Version Control Forks

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.

Simple Implementations of Feature Flags in Rails

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.

Adding the CloudBees Feature Flag Rails Gem

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 conditions on and off.

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:

xxxxxxxxxx

# 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. It's cool to note that ,in the same account, you can configure multiple apps and their respective flags.

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 out CloudBees Feature Management for yourself.

This post was written by Taurai Mutimutema. Taurai 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.