9 Best Practices for Release Management

Creating release management flags is a three-part process: planning, implementation, and deployment. Consider the following best practices for each phase in the process.

1. Planning

Make feature flags a priority from the start
Again, the right time to think about whether a feature needs a flag is during the design process. The design of a feature may vary based on whether or not it is behind a flag. When feature flags are an afterthought, you end up with flags that don’t work as expected, don’t target the right users, or have unexpected behaviors.

Thinking about a feature flag during the design phase requires you to consider who will use the feature. If you determine the feature is for larger enterprises during the design phase, you know that targeting customers at small or mid-sized businesses would not be appropriate.

Understand the purpose of a feature flag
A flag can serve many purposes. Release flags can control how a feature rolls out to users as well as serve as a kill switch if something goes wrong. If a flag will serve multiple purposes, notify all parties and make sure everyone has access to the flag.

Establish naming conventions
As mentioned earlier, a consistent naming strategy ensures everyone understands the purpose of the flag and ultimately helps avoid technical debt.

2. Implementation

You’ve planned the feature; now you’re ready to implement the flag. Questions to ask to determine the deployment path:

• Do features get deployed to staging, pre-production, or test environments before rolling out to production?
• How will you roll out the feature to users?
• Is it first used by developers, then internal staff, then external users?
• Will there be a beta or a canary launch?
• Will release occur through a controlled rollout or to all users at once?

There is not a right or wrong answer when it comes to how you deploy, but to create an appropriate flag, you need to have a deployment plan in place.

Test the behavior of the feature flag
We are big proponents of testing in production. However, this doesn’t mean you only test in production before you deploy a flag—you should test the behavior of the application with the flag toggled on and off. This is especially important if the feature is related to a schema or database change. What happens when a feature is on and then toggled off? Is data lost or corrupted?

Another aspect of testing is dogfooding—using your own product or service internally. This lets you test out changes on internal employees first. Put yourself in your customer’s shoes. With dogfood environments, you can see firsthand the pains that users might experience with a feature. Using the application as a user would use it is a step towards empathy-driven development.

You can test all you want before deployment, but until customers use the feature in production, you won’t know if it is working and what needs to be changed. This is why we regularly endorse testing in production.

Configure a fallback value
What happens with a flag if a user is not able to access the most recent settings? What happens if a user accesses your application in offline mode? Configuring a fallback value can eliminate unexpected experiences or errors with interrupted connections. Every flag should have a fallback value describing the expected behavior of the feature in case failures occur during evaluation. Should the flag be on or off by default?

Keep features small, but not too small
Not every feature needs a flag, and sometimes a feature needs multiple flags. You don’t need to wrap a tiny change in a feature flag unless you’re very concerned about its impact to users. Large features such as a new dashboard might require multiple flags.

Create segments or cohorts
Before you deploy, you need to determine how to segment your users. Identify which attributes determine who sees a feature when

3. Deploying

You’ve planned and implemented the flag; all that’s left is to cross your fingers and deploy to production. Wait, not so fast! As you deploy, consider the following:

Track metrics
What metrics do you need to track regarding features? Availability, reliability, and response time of an application should not change with the deployment of a new feature. Set up monitoring to track performance before, during, and after you deploy code to ensure performance does not get worse. Tracking metrics such as page load time, errors, uptime, conversions, or user registrations can tell you whether a feature is performing well or causing problems. The metrics you track will vary based on your business and objectives.

Avoid technical debt
Release management flags should be short-term. This means you should remove a flag after it has rolled out to 100% of users, as mentioned above. Technical debt accumulates when you forget to remove a flag from the code. Put processes and reminders in place to remove the flag.