There may not be a single right way to manage feature flags, but there are best practices that we have learned from our customers and from our own use of feature flags. The goal of this post is to share some of those best practices to help you manage your feature flags as efficiently as possible. There are also some helpful features we provide within Flagsmith that make management easier; we’ll point those out so you can get the most out of your implementation.
This short guide will help you understand some of the best practices to apply when using feature flag processes and how to manage them effectively.
Tips for managing feature flags effectively
Here are a few tips for managing feature flags effectively.
Applying some best practices is important, especially when you have a large number of flags operational at any one time, and multiple team members working together on a project. Things can get complicated!
Have Clear Naming and Descriptions
Step one is about staying organized. As soon as you’ve got more than one feature, things can get complicated. That’s why tip number one is all about classifying your features.
Create a naming convention
It’s a good idea to decide on a naming convention up front. Ideally, your feature names should communicate what the feature is and what it does, as this will allow other developers to get the information they need right away. In Flagsmith, the name is referred to as the Feature ID. You must choose an ID when you first create a feature and you cannot rename a Feature ID, as you use that Feature ID in your code. Choose your convention up front and stick to it!
Use clear and thorough descriptions
Just like adding clear comments in code makes better code, adding clear descriptions to your features makes them better. Like code comments, they should be concise descriptions of what the feature is intended to do and why. In Flagsmith, this is the Description. It is optional but we advise that you use it consistently. The description can be changed at any time.
Add tags to your features
Not all feature flagging software provides the ability to add tags to your flags, but we find it very useful. Once you have created a feature you can edit it and add one or multiple tags. They are optional and can be edited at any time. Tags help you quickly filter features and since they can be different colors, they allow you to identify the purpose of different features at a glance.
You can use tags to classify features in different ways. Some teams classify their features based on the service that they are part of. Others group them around the teams that are working on them. Use a taxonomy that best fits your team and product. You can also classify them based on flag role; some flags might be used to roll out new features and hence have a limited life span. Others might be used to control what features are shown in different payment plans.
Use Projects and Environments
While on the topic of keeping things organized, here are a few notes on setting up your Organization correctly. Within your Organization there are Projects, within Projects there are Environments. You can add as many Projects and Environments as you like, but we recommend keeping a rule in place so everyone understands when to create a new Project or Environment.
We recommend using a new Project when it is a distinct application or when a different team works on the features so that you can manage access controls appropriately. An example of this would be a Project for front-end and one for back-end, or a Project for the mobile application and a Project for the web application. There’s usually only a few Environments — development, staging and production are normal, but you can create per branch or per developer environments if you wish.
Projects share flags within their environments, so use this to guide your taxonomy.
Set up Access Controls
Our first tips were about staying organized, this second one is about security. The last thing you want is a faulty feature to be switched on at the wrong time and go live to your entire user base. That’s why access controls should be used to give people different levels of control and restrict usage. Just like with other software permissions in your business, the best practice is to only give users the access that they need to do their job.
Flagsmith’s Scale-Up and Enterprise plans offer role based access controls that allow an Organization to manage access for users at a detailed level. Also helpful is that users can be categorized into groups and permissions can be managed at the group level. Users are given roles at the organization level (Administrator or User), and controls for users or groups of users can be further managed at the project level and the environment level (read environment, delete features, etc).
Clean Up Old Flags
When a feature has been completely rolled out and is no longer needed, it should be deleted. Having old unused features makes managing your flags more difficult and can lead to confusion or even conflicts. As we noted above, adding a date in the ID or description can help with this. Flagsmith’s upcoming Flag Analytics can also really come in handy here. Flag Analytics will show you the last time a feature was evaluated within your code, so you can quickly see which flag can be removed. Be sure to check this periodically and clean up old unused flags.
Maintain and Use Audit Logs
It’s a feature flagging best practice to keep a log that tracks any features that are created, changed, or deleted, and who took those actions. This is especially important if you have a large number of developers working in different teams. Having this information can save a lot of time and confusion in knowing what has been done, when, and by whom.
Keeping a log is important, but also an extra step of work likely to be missed from time to time. That’s why Flagsmith has a built in Audit Log that tracks every action taken on flags, identities, and segments. It’s viewable in the app and easy to search or it can be streamed with webhooks. We recommend becoming familiar with the logs.
Final Thoughts
As we mentioned, there isn’t a right way to manage feature flags — you will find what works best for you and your organization. However, these best practices should save you a lot of time in the management of your feature flag implementation. Then you can spend more of your time building products and testing features that delight your users!
