Satisfying the feature request of our customers from the mobile app development industry, ConfigCat now supports semantic version (SemVer) based user targeting.
Typical use case where app builders wish to enable or disable features based on the iOS or Android version on the device their app is running on.
For example deciding if 2.3.40 is less than or equals 2.30.4 sometimes not that straightforward by only using the traditional <>= comparators.
Show us your most innovative idea in using feature flags with ConfigCat
and we’ll send you a pack of gifts including your choice of video or music
streaming worth $100, or books worth $150 + a pack of ConfigCat and GitHub swag + a commercial ConfigCat subscription.
How using feature flags makes your product development successful and safe?
By the given example you can follow the process from idea to satisfied customers
Software (or even hardware) development could be a real challenge. Not just because it needs all your attention and a lot of time to do but you cannot be sure (even if you made research on the market) that your customers would like the new feature or product.
That is the reason why product development is not just a part of a job, but it is an independent work. It needs specialists, managers, tactics, and tools too. Having a good idea is far too little to give off the perfect software product - you are going to need the best people and the best tools for that.
We'd like to make ConfigCat avaliable for as many users as possible. Our SDKs are avalible 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 plannig to support ruby?"
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.
You created a new software feature, put it behind a feature flag, and deployed it to production.
Now, you want to enable this new feature to some of your users, so you get early feedback, before releasing the new feature to your whole userbase.
But whom to release the new feature first?
How to choose the first user segment?
And how to target them with feature flag rules?
Lets see some typical real world examples how big companies do it.
Release based on Company, or Email address
A great first step is to enable the new feature to your colleagues, while keeping it hidden from the rest of the world.
This enables you to get early feedback from users inside of your company.
You'd be surprised how much bug they'll catch on the first day!
Here is how you can segment and target your colleagues with one simple rule in ConfigCat:
If you're a software reseller you are allowed to buy a ConfigCat subscription for your client.
You are allowed to resell one subscription to one client only.
Of course, you are allowed to resell more subscriptions to the same client.
2FA is a way of granting access to users only after presenting two separate pieces of evidence (factors). One of these factors is usually a password which the user should know and the other factor something they have or even something they are. This way you can be sure that only knowing your password won't be enough for an attacker to gain access to your account.
How does 2FA work in ConfigCat?
In our case the first factor is password you use to login to ConfigCat Dashboard. The second factor is a 6-digit number generated via an Authenticator App.
As feature flags are getting popular, an ever-growing number of developers are facing the challenges associated with them.
No matter if you implement your own feature flag library, or choose a hosted feature flag service like ConfigCat, chances are high you want to use your feature flags in your frontend and in your backend services as well.
If your feature flags can be toggled on a central feature flag dashboard, such as
