David Herbert

Feature Flagging is a powerful technique that gives businesses and organizations granular control over features by providing the ability to scope these features to a specific segment of users.

Feature flags are helpful for many reasons - one of which is they allow organizations and engineering teams in a multi-tenant software application to limit access to certain features by mapping them to the various tenants in the application or organization.

Feature flags (aka. feature toggles) are becoming increasingly relevant in software development as they provide the ability to toggle features on or off in production, perform a gradual rollout of features and enable A/B testing experiments.

However, an often overlooked part of this feature flagging technique is that it introduces complexity and has inherent risks when said complexity isn't properly managed. As you're using more and more feature flags within your organization, it's important to understand that some of these flags are meant to last only for a short period and should, therefore, be removed from your codebase.

As developers, we spend countless hours building new features and having them pass through rigorous QA tests. However, despite experience and all preparations made, there's always that dreaded feeling you get in the pit of your stomach when you know it's time for deployment. What if something goes wrong in production and your feature doesn't function as expected?

In a traditional software development workflow, whenever there are updates or feature releases to be made, they are typically tied to a single major deployment to production. As a result, the frequency of feature delivery is slower and a lot riskier because there’s a lot more at stake with each deployment if things don't go as planned.

That is to say that releases should not be tied to deployments but rather, decoupled from them. Due to this reason, in a continuous delivery environment, it is considered best practice to decouple feature releases from deployments as it allows for more incremental releases.

Hence, understanding the concept of decoupling releases from deployment and how feature flags can make that possible is a key for any team.

There's nothing more frustrating than writing up a thoughtful, intentional feature request to your favorite service provider and then not getting a response or subsequent feedback.

At ConfigCat, we understand the importance of feature requests because we know that our service becomes more successful when our customers are happy and their needs are met.

As a result, we keep track of each of our customers' feature requests to help us make informed product decisions and implement the features that matter most.

Product managers are responsible for deciding what products to develop that align with the company's goals and also satisfy the needs of the customers. To be a successful product manager, you have to start by defining what a winning product looks like and iterate over it until it's right. To do so, you have to understand that at its core, a product is broken down into its features and quality of user experience.

However, when developing these features, even after thoroughly testing them in your development environment for potential bugs and issues that may negatively impact user experience, it may not always be sufficient to ensure a successful release to users.

Remix, the React-based full-stack framework for building server-rendered applications, has been generating a lot of buzz lately, especially since it was open-sourced. Remix is a dedicated Server-Side Rendering (SSR) framework for building web applications that are rendered on the server.

In this post, we’ll look at how we can easily implement a canary release of a feature in 7 steps using ConfigCat’s feature flagging service through its provided dashboard.

This step-by-step guide will showcase how we can release a new feature incrementally, by first exposing it to low-risk user groups (e.g. team members and possibly friends), and then gradually releasing it to a larger audience - using ConfigCat, a feature flag service to implement everything.

Feature flags have greatly simplified the process of continuously testing and integrating new features into our applications. They ensure confidence even in production environments, eliminating deployment risks such as downtimes or bugs that could adversely affect the entire user base.

Building a modern application often involves building it as a microservice, which provides developers with more flexibility and agility in terms of deployment options. However, deployment can either be a joy or a nightmare, depending on the strategy used, whether it's deploying microservices, testing new features, updating a business logic, or releasing a new version entirely? With every code change pushed, comes the risk of potential failures, which could be as a result of bad code quality or unexpected bugs, and this can potentially disrupt the user's experience.

Hence, picking an efficient deployment strategy is key to mitigating these deployment risks and not having to constantly disrupt your user’s experience by going into downtimes or completely having to go offline whenever there is something to be deployed.