Transitioning to GitLab for source control for Ledgerpost, offered a fresh experience compared to my familiarity with GitHub. A standout perk of GitLab is its generous provision of Feature Flags—at no cost for the first 50 flags. This functionality positions GitLab alongside specialized services like LaunchDarkly and CloudBees, making it an attractive choice for developers looking to manage feature rollouts effectively.
TL;DR - Just give me the solution
Sometimes you are unsure if the feature you want to implement will resonate with your users. Before you embark on the path on a multi-month roadmap you can put in minimal amount of effort into a new feature and roll it out to a select group of users, allowing you to gather valuable feedback and assess the feature’s impact before a wide-scale roll-out.
Smaller Pull Requests
When trying to do high quality code reviews, it’s difficult to wade through a 50+ file PR that could take weeks to ship. The longer the PR takes to deliver, the focus declines and bugs can slip through. Additionally, if there are other engineers working on the same codebase, this increases the likelihood of merge conflicts which causes pain and generally increases friction. If we want to increase the efficiency and productivity of your team, we need to ensure these PRs remain small and each story/feature can be delivered in no more than 3 days. Always be shipping. If you break down that large, 11-point story into a multi-story Epic, we can employ Feature Flags as a control mechanism to hide the work-in-progress features from the users.
Introducing new features carries inherent risks. Users may interact with your product in unexpected ways, leading to unanticipated bugs that can erode trust in your application, potentially causing user attrition. A more cautious strategy for feature release involves a targeted approach: unveiling new functionalities to a specific subset of your user base or incrementally to a percentage of your audience. This method allows you to gauge user response and system stability, providing a safeguard against widespread issues.
Extract Conditional Complexity from your Business Logic
Embedding conditionals directly into source code for user-specific feature access is not ideal. It entangles your business logic with user access controls, and updating the access list means submitting a new pull request (PR) and deployment each time. By delegating this logic to a feature flag service provider, I gain the flexibility to alter feature flag configurations on the fly. This approach eliminates the need for immediate code changes and PRs, streamlining the process and keeping the business logic clean.
One of the primary considerations in selecting a feature flag configuration provider is cost. GitLab stands out by offering this service free of charge, which is particularly appealing for teams looking to minimize expenses. While LaunchDarkly leads the market with its feature-rich platform, starting at $8.33 per month per user, and CloudBees offers a free community version, my hands-on experience with GitLab has been overwhelmingly positive, solidifying my preference for it over CloudBees.
In the corresponding repository of the application, go to “Deploy > Feature Flags”
- Click on “Configure”
- A modal will appear and copy the
Instance ID, we will inject these into our app via environment variables.
- Dismiss the modal
Let’s create our first Feature Flag
Back at the main Feature Flag menu, click on the “New Feature Flag” button
For our feature flag name, I like to use the format of
<action>_name_of_feature. In this instance, let’s call it “enable_hot_new_feature”
For Type, click on
User IDs, enter
For Environments, this will be the environment in which we intend to have this Feature Flag active. In this instance, let’s just call it “ALL”
Add To Your Rails Code
The way that GitLab is providing their Feature Flag management tool is by way of the Open Source project, Unleash.
If you’re using ruby, you’ll need to add the
bundler add unleash
Then we’ll need to create an Unleash initializer file:
Unleash.configure do |config|
config.app_name = ENV['UNLEASH_APP_NAME']
config.url = ENV['UNLEASH_URL']
config.instance_id = ENV['UNLEASH_INSTANCE_ID']
config.logger = Rails.logger
Rails.configuration.unleash = Unleash::Client.new
UNLEASH_APP_NAME does not refer to the name of your application but the name of the environment you intend to have the Feature Flag reflected in, e.g. production, or in this instance “ALL” as we stated above
Before we test it out in rails console, we’ll need to update the file that you use to manage your environment variables whether it’s in your
.env file or your
config/application.yml file via figaro and set them accordingly.
After that is setup, you can run
context = Unleash::Context.new
context.user_id = "1" # Note the type needs to be String
context.user_id = "2"
In this instance, I’m testing to see if only the User with id=1 can view/use “hot_new_feature”.
If we don’t want to tie the feature to a user, maybe it’s a binary OFF/ON feature, we could do:
You can read more about the various Feature flag strategies on the GitLab documentation page