The Complete Guide to Feature Flag Management

Feature Flags: Everything you need to know 

Feature flagging is a software development technique that enables teams to make changes without deploying new code and allows for more controlled experimentation over the lifecycle of features. This is an excellent way to validate your features earlier on so that you can ship code more frequently, and with confidence.

A quick definition

Feature flags are a tool that enable product and development teams to toggle on and off select functionality at the push of a button — without the need to change any code.

One of the most innovative aspects of feature flags is that they allow teams to make changes without pushing additional code. This means there can be many experiments over time with features while still maintaining a controlled environment. This process is beneficial for agile management workflows, and works to promote CI/CD.

When a new piece of code is ready, it can be wrapped in a feature flag. This means the code will be deployed to production as usual, but it won't activate in production until the feature flag has been explicitly activated. Flags can also be assigned to or gradually rolled out to a subset group of users, which is a great way to target behavior for specific users.

What are the advantages?

Feature flags are useful because they provide more control to the development team. Development teams can have code committed and deployed to production in a dormant state, then activate it later. The result is that new code only affects specific users so that the user experience of the end product is preserved.

Developers can leverage feature flags to perform “soft rollouts” of new product features. New features can be built with immediate integration of feature toggles as part of the expected release. The feature flag can be set to "off" by default so that once the code is deployed, it remains dormant during production and the new feature will be disabled until the feature toggle is explicitly activated. 

Teams need to be incredibly meticulous when they introduce new code. They have to have a foolproof plan and rigorously test it first. After testing, they can turn on the feature flag to activate the new code. But if there's an issue during this process, they can turn off the flag to minimize user exposure and fix the problem as soon as possible.

You may want to consider using a feature flag when the system is overworked. You should do so to protect your intermittent issues from the attention of customers. If your application is getting too much traffic and the metrics show an increase in issues, you can turn off poorly performing or non-crucial features.

Feature flags can help you minimize complicated code integration and deployment. If you're deploying a new feature or performing sensitive refactoring work, it can be difficult to integrate these changes into the main production branch of your repository. This becomes even more complicated if multiple developers are working on overlapping parts of the codebase. Feature flags can help you minimize this complexity by decoupling new features from the production codebase, which in turn makes testing and deployment much easier. 

While new code is being developed, it's important not to disrupt the current work-flow. Developers avoid long-running feature branches by committing frequently to the main branch of a repository behind the feature toggle. Once the new code is ready, they're able to toggle the feature flag to enable the new system with no interruptions to the rest of the team.

How feature management relates to progressive delivery

In the iterative and continuous world of software engineering, developers must constantly be pushing code to a repository. This branch-intensive workflow is a good thing, as it keeps your main branch clean and constantly in a release-ready state. It also allows developers to experiment with new things without stepping on their teammates' toes — a necessity in agile environments. It can also help project management become easier since you can easily track the progress of a new feature, beta test, run QA tests, or rollout certain features to specific users.

In order to make sure that each development branch is completed and ready for merging into the master branch, always create a development branch before implementing any code changes. Once you're done with your changes, merge them down into the master branch and then release them whenever you're ready.

Improving DORA Metrics with better feature management

In 2018, Google acquired the DevOps Research and Assessment (DORA) team to find out how teams can create high-performance and high-value software. The group published their best-known studies in order to answer questions and provide guidance for how teams can continuously improve their processes and capabilities. The series of annual reports (known as the State of DevOps Report) includes a benchmark to measure progress and a set of best practices to implement DevOps practices.

The DORA group found that the best software teams will optimize for four metrics:

1. Change Lead Time
2. Deployment Frequency
3. Change Failure Rate
4. Mean Time to Recovery (MTTR)

Feature flag management helps teams release code frequently and easily resolve bugs that align with DORA metrics.

Change Lead Time

Change lead time is the amount of time it takes to develop a fix and deploy it to production. Shortening lead time means more efficient development. Lead time is the total amount of time between when an issue is selected for development from code commit and when it's deployed in production. 

Deployment Frequency

Deployment Frequency is the frequency at which you deploy changes to production. This indicates how quickly your team is working. According to DORA, high-performing teams deploy smaller and more frequent releases. This is a great way to increase customer satisfaction and decrease risk. When it comes to bug fixes, the smaller the change, the quicker the fix. You can lessen the chances of production failures by minimizing the size of corrections and updates. 

Change Failure Rate

Change Failure Rate is how often a change you make on your website results in an incident, error, or failure. This measurement is a sign of the quality of the code you are pushing to production. The fewer mistakes the team here makes, the better. The ultimate goal should be to keep this number as low as possible over time, as skill and knowledge improve. 

One of the most difficult components of setting up a supportive environment to tackle failure is defining what failure is. If the definition is too broad, you'll encourage the wrong behaviors. If the definition is too limiting, then you'll fail to recognize opportunities for change. In the end, and always, the definition of failure must be unique to each organization, service, or team.

Mean Time to Recovery

Mean Time to Recovery (MTRR) is the measurement of the time from when the incident occurred until it was resolved by a production change. The goal of optimizing MTTR is to minimize downtime and detect, diagnose, and correct the inevitable problems that arise.

Engineering leaders have the power to define your team's success. You can empower them with direction and tools through DORA metrics and trends. This data will make it easier for developers, teams, and engineering leaders to identify problem areas and make improvements. Doing this will provide the team with the necessary tools to accomplish their goals.

When your DORA metrics improve, you can be confident that you’ve done a good job making and implementing decisions to empower your team. You will also have delivered more value to your customers.

Choosing the right software

There are many paths to take when adopting feature flags. The path you take depends on your team's needs and organizational goals. When it comes to feature flagging, a third-party hosted solution is the best choice. These services handle the heavy work and offer an easy installation process. This allows team members to focus on their core duties (releasing impactful, reliable code) instead of implementing the infrastructure for a feature flagging tool. 

When choosing a feature flagging tool you should consider data security, how many flags the platform allows you to have, the number of seats, data security, and ease of implementation. Other factors to consider include customer support, the level of documentation, scalability if it allows for experimentation along with the overall price. It’s common for feature flag tools to have additional hidden costs such as paying for seats that aren’t used, paying for additional flags and experiments. You can read more about the leading feature flag platforms here to find the best solution for your team. 

Get started with DevCycle

Feature flags can be powerful additions to an agile development arsenal. Many developers use them creatively, and they're complementary to continuous deployment. Feature flags are a useful tool for teams who want to control the codebase, deployment, and the end-user experience. Get started with a 14-day free trial of DevCycle.