When it comes to releasing new features or changes in software, we can rely on A/B testing for making informed decisions. In this type of testing, we can measure the impact of the new change or feature on users before deciding to deploy it. By doing so, we can carefully roll out updates without negatively impacting user experience.
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:
The world population continues to grow, and so does the number of house pets. While we all hope most of them have a good quality of life, some don't have a home. To combat this, we can make an animal care app. In this blog post, the app's objective is to increase the pet adoption rate. We will change the color of our call-to-action button and measure the click-through rate of each button version using A/B testing.
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!
The goal of software development workflows is geared toward releasing new features and updates, which can sometimes cause issues if not handled correctly. In my opinion, using feature flags has proven to be essential in situations like these. You can use them to easily deploy new features, and if there are bugs you can quickly turn a feature off, then turned it on again when they have been fixed without having to redeploy the app.
By now, you’re probably well-acquainted with the suite of useful feature flag tools offered by ConfigCat. In case you aren't, ConfigCat is a developer-centric feature flag service with unlimited team size, awesome support, and a reasonable price tag. Let's play it safe and discuss 3 cool things that ConfigCat allows you to do – which we bet you didn’t know about! I’ll cover:
Let’s get started!
Autumn of 2021 saw the release of the newest .NET version, .NET6. This new release brought some updates that could potentially make a developer’s life easier, such as improved performance and a simpler development process. With less code to write and productivity tools like hot reloading, the new .NET was quickly adopted by developers all over the world.
Even before the new release, .NET had a wide range of utilities and has risen to become of the most popular frameworks available. Whether you’re migrating from an older version or just getting started on a new project, you may be wondering what feature management solutions are available to you. I wondered as well, so in this tutorial, I’ll go over one of the best - using feature flags.
If you’ve been reading about feature flags then I’m sure you’re convinced of the power and value they provide. Since development is mostly a team effort, you may be wondering how to manage a feature flag within a team, regardless of size, so one developer’s work doesn’t affect another’s. Well, in this article, we discuss exactly this issue and offer two solutions, depending on the size of your team.
Let's say your team has developed a new feature update and is planning to release it to the public. There can be some uncertainty and risk because it is hard to predict how users will react to the change. Will the new update have a negative impact and drive users away from the app? The best way to know for sure is to adopt an A/B testing approach by releasing it to a subset of users to measure its impact prior to making a full deployment. This gives you enough room to uncover bugs and refine the feature without disrupting the experience for everyone.
Picture this: You’ve added a new feature to your software, linked it to a feature flag, and deployed it to production. Now, you’d like to enable this feature for a subset of your users to get their feedback before you take the leap and roll it out to everyone.
But who gets to see this new feature first? How do you choose the first user segment? How do you use feature flag rules to target them?
Good to know: Feature flags let you launch new features and change your software configuration without (re)deploying code.
Let’s look at some typical real-world examples of how you can do canary releases using ConfigCat.
