Skip to main content

ConfigCat using it's own feature flag service

· 4 min read
Lajos Szoke
Lajos Szoke
The one man army, who single-handedly built the heart and soul of ConfigCat.

ConfigCat is using ConfigCat as a feature flag and configuration management service. Here is how and why.​

inception

  • We saw a lot of strange things during our developer carreer, and one of the most hated things were the well-known MERGE HELL situations. We didn’t want long running branches with days of merging and scratching our head before releasing the actual code. Now we are just using simple feature flags and merging our feature branches back to master as soon as possible. There are many ways to implement feature flagging. Using ConfigCat is one of them. So we took the chance and started to use our own service as a feature-flag-as-a-service provider. (Dogfooding, yes).

  • As our new features are protected with feature flags, we are very confident about turning them on. What could possibly go wrong? We can turn them off anytime if our error tracking service starts yelling at us.

  • It is inspiring to go to a team outdoor camping trip in the middle of nowhere and with using just our phones turn on a new feature on live.

  • We can test in our live environment without actually turning on the feature for every single user, only for the ones we choose to. A great real-life example was turning on our payment service in our live environment where we wanted to make a first test payment before any of you can do it. So we just set up a targeted rule in ConfigCat which only allowed our test users to access the payment service. Actually, this was a success story for ConfigCat, because we forgot to change a webhook URL from test to live environment at our subscription and payment service provider. How bad would it be if any of you paid for ConfigCat and didn’t get the promised service itself?

How do You, our current and future customers benefit from ConfigCat using ConfigCat?​

  • As we use ConfigCat in our daily routine not just as developers, but as real customers, we can tackle down the pain points in our service to make it much simpler to use. We used too many complex, over-engineered tools over the years, so we don’t want ConfigCat to be one of them. Another excellent example is the way we handle different environments like DEV, STAGE, LIVE. In the beginning, we prioritized this feature to a later phase. As I had to create the sixth setting in 2 projects to handle our test and live environment separately, I felt like I was going to be crazy at the end of the day. That day we implemented environment handling in ConfigCat and the day after we started to use it.

  • Let’s just imagine a situation when a bug is getting released to our live environment.

What would we do without ConfigCat?​

  1. We find out that there is a bug in our live environment. Minutes passed: 0.
  2. We are trying to fix the bug at a crazy pace. (Remember! The amount of bugs in your code is usually constant :). If you are fixing bugs panicked, this amount will just increase.). Minutes passed: 25.
  3. As we managed to fix our bug, our release pipeline comes alive with minutes of building, testing and releasing. And you are just sitting there waiting for it to complete the deployment. Minutes passed: 40.

How is it with ConfigCat?​

  1. We find out that there is a bug in our live environment. Minutes passed: 0.
  2. We turn off the feature which caused the bug. Minutes passed: 1.
  3. You can use ConfigCat without any problem. Minutes passed: 1
  4. We just started to make a coffee before fixing the bug peacefully. Depending on the coffee machine, minutes passed: ~5