Skip to main content

An In-depth Look into User Targeting

Jan Sipos

Jan Sipos

One good test is worth a thousand expert opinions.

Let's say you've just built a new feature, but it's not ready for a full release just yet. So, you decide to test it with a small group of people.

Image with sticky notes

You can go about it in two ways - deterministic or random. The first way lets you specify people by name, email, company or any other attribute you know about them. The latter uses fancy math and probability to randomly assign users into groups. Let's see how you'd accomplish both using ConfigCat.

Enable my feature automatically

Endre Toth

Endre Toth

Large scale enterprise development expert. The father of our SDKs and infrastructure.

When I implement a new feature to my application, I would like to manage it after the release (enable, target, tune and obviously in urgent cases roll it back). The feature/release toggles design pattern can solve my issue, but how can I answer the business needs? For example:

  • turn on the feature on Sunday at 12 PM
  • increase the discount value of the promotion every workday
  • enable the feature only on weekends or on weekdays

ConfigCat鈥檚 Reliability Framework

Csilla Kisfaludi

Csilla Kisfaludi

Girl in Tech. Mother of None. Pretty in Pink.

When we designed ConfigCat, our main purpose was to create an architecture that is scalable and resilient to short interruptions, so you don't have to worry about latency, service outages, and unwanted glitches in the system.

ConfigCat's Global CDN map

Feature flags in multi-developer environments (Best pratices)

Zoltan David

Zoltan David

One with a vision, answers and a master plan.

When it comes to feature flags, teams with 5-20 engineers face similar challenges to teams with hundreds of developers. What you never want is one engineer flipping a feature toggle to unintentionally affect the work of another engineer.

This is a conceptual problem with feature flags. It doesn't matter if you are using an open-source feature flag tool, or a feature flag service. Let's see best practices ConfigCat recommends.

ConfigCat Stack ep.1 - Overview, POC

Lajos Sz艖ke

Lajos Sz艖ke

The one man army, who single-handedly built the heart and soul of ConfigCat.

In the next few articles I would like to introduce the core infrastructure of ConfigCat, how it has evolved over time and what challenges we faced through its validation phases.

ConfigCat, meet Zapier

Ever since we heard about Zapier we have been ecstatic by the possibilities this could bring to our platform. Zapier is an integration platform that allows you to easily connect multiple platforms by taking inputs from one service and outputting them to another service. While software integration is common, some integration may not be appropriate for your technology stack, or native integration may not yet be supported. This is where Zapier can step in and save the day.

Introduction to our new Public Management API

It truly is an exciting day for ConfigCat, we would like to introduce a brand new way to use our platform via our new public management API. This new feature makes it easier than ever to test and manipulate your feature flags allowing you to create, read, update and delete any entity within ConfigCat, such as Feature Flags, Configs, Environments or Products. For anyone familiar with using Public Management API systems the benefits will be beyond clear, if you are not, we will show you in this blog how you can make feature requests quickly and easily, all without writing any external code.

Connect and monitor feature flag changes in DataDog

Endre Toth

Endre Toth

Large scale enterprise development expert. The father of our SDKs and infrastructure.

A updated version of this blog post is available here.

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.

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:

DataDog Dashboard