Endre Toth

Feature flags are a great way to control the release of new features in your software. They allow you to easily turn new features on or off without redeploying your code.

However, when implementing a feature flag in an application, we may want to customize its management after the initial release, i.e., schedule an incremental release/delivery strategy that is carried out automatically or schedule future changes to a flag's targeting rule that can take effect at specific time intervals.

For example:

• Activate a flag’s config by date and time. For instance, release a feature at noon on a Sunday afternoon.
• Gradually increase the discount value of an ongoing promotion at specific times of weekdays.
• Enable a feature only on weekends or on weekdays.
• Three days from today, turn on a feature for internal testing and enable it for public use a week later.

Got some free time on your hands? Got you covered!

I'm going to show you a more peculiar way of using feature flags. Feature flags enable non-developers to switch on and off application features or change software configuration.

Following this step-by-step tutorial, you'll build a remote light switch using a Raspberry Pi and ConfigCat’s feature flag tools in no time. Let’s get started!

Features can sometimes reach a high-enough level of complexity that simply cramming the entire thing behind a single feature flag and calling it a day becomes widely impractical.

More modular feature control needs to be thought of and implemented beforehand. Since such scenarios happen quite often all throughout development, a more advanced form of feature flag management is needed.

Understanding the Flag Hierarchy​

While the base concept of feature flagging remains untouched (in the sense that they still toggle stuff on and off), feature flags nowadays tend to act more like an interconnected web of toggles where they may or may not be dependent on each other to run. The main benefit of all this added complexity is the ability to use flags to control certain parts of a feature in a very modular and clean way.

Thanks to the latest CI/CD tools and services, software companies can now deliver multiple releases in a week. Over the release process, it's expected that DevOps professionals keep their eyes on the monitoring dashboard and roll-back the deployment on the first suspicion. Since the use of feature flags gets more and more traction, it seems like a good idea to connect those releases and the monitoring tools.

Nowadays, thanks to modern continuous delivery tools, many software development processes make it easy to deliver multiple releases per week. It is often common for several scheduled releases per week to be released. The usual practice is that during the release process, DevOps guys keep their eyes on the monitoring dashboard, and if they find any anomalies, they roll back the version.

But what happens if someone changes a feature flag's value (release toggles) in the production environment?

Release Toggles allow incomplete and un-tested code paths to be shipped to production as latent code which may never be turned on. https://martinfowler.com/articles/feature-toggles.html

DevOps are notified that a certain threshold has been reached for the production environment and that when they open a related metric they see something similar:

We'd like to make ConfigCat available for as many users as possible. Our SDKs are available in multiple languages. But still lots of our users missed Ruby support in ConfigCat:

• Does configcat have Ruby sdk??
• So I am sad you don’t have a Ruby client I can see.
• Are you planning to support Ruby?

The Ruby SDK​

Finally we decided to create a standalone Ruby SDK.
Ruby is an interpreted language. It's very similar to Python and we already have an SDK written in Python. Taking advantage of this, the first idea was that we simply convert our Python code to Ruby and everything will be just fine.