For a long time, it was normal to initially release a new feature or update into a test environment. If the feature passed, it was then released to the production environment. While this approach was highly respected and beneficial, it introduced more complexity into software development workflows, and releases took longer to reach end-users. Fortunately, with a mechanism known as feature flagging, you can deploy directly to production and ship releases faster while maintaining reliability.
There’s nothing quite as exciting as seeing your app live on Google Play or the App Store. The culmination of months, if not years, of hard work can bring a sense of accomplishment, but with it comes the pressure of ensuring that your digital product functions as intended and meets the needs of your users.
Whether you’re planning to launch your first app or are a veteran in releases, you’re probably aware of the review process your app must go through before it can go live on the store. These reviews can take anywhere from a few hours to a few days, depending on the complexity of your app and the number of apps waiting to be reviewed.
Feature flags are essential for effective feature release and management. Using them, we can control what features end users can see and which should remain hidden. Feature flagging allows developers to plan, launch and test new features remotely without editing code. While these benefits are fantastic, what about code testing? Having some methods in place for testing the integration of feature flags in our code can increase the likelihood of smooth feature integrations.
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.
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's feature flag services. For context, ConfigCat is a developer-centric feature flag service with unlimited team size, awesome support, and a reasonable price tag.
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.
Most companies believe they understand the customer, only to be shocked when their customers behave differently than what they expected, either intentionally or unintentionally. That's where A/B testing comes in to kick all these doubts and prevent the shock.
We’ll play around to see how A/B testing works with ConfigCat’s feature flag management service to take your experiments to the next level by giving you the ability to remotely control and configure your features without going back to the code.
This is a step-by-step guide on implementing an A/B testing scenario using ConfigCat and visualizing the results in a funnel with Amplitude. There is a working sample application on GitHub if you want to follow along.
Separating your customers into distinct segments will help your product in all sorts of ways. It can help you track the usage of your app in a more meaningful and granular way. It can also reveal how specifically different segments behave differently, which will help you prioritize future feature development as well as focus your marketing efforts.
