Feature Flags in Rails: Get Started Quickly and Easily
Using feature flags, Rails allows you to rollout new features in a safe and surprisingly easy to manage manner.
Join the DZone community and get the full member experience.Join For Free
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.
After this command successfully adds the gem to your project, you then add the Ruby SDK by adding the following code:
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.
Published at DZone with permission of Kiley Nichols, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.