Feature Toggles: 7 Best Practices for your Dev Team
Share this on:
Does your business have a Dev team? If so, then you know how complex the process can be, whatever their end goal is. When it comes to implementing a product, new software, or even a service, there can be multiple issues that may arise and keeping a close track on how they are working and problems they encounter can be crucial to success.
One problem – or hurdle – that is frequently encountered in software development is knowing how your product will behave in different scenarios. Rewriting or creating new code and language can be a time-consuming and laborious process, so being able to turn off different areas of code can be very helpful. This is done with the help of feature toggles (also known as feature flags). Just what are feature toggles and how should your dev team be utilizing them?
What are feature toggles?
Imagine for a minute moving around your room switching different lights on or off to achieve a desired ambience. In essence, feature toggles are designed to achieve the same effect but with performance the goal rather than ambience. They allow your dev team to turn parts of the code on or off without any need for deploying.This can help when developing applications such as enterprise meeting software.
Dev teams will use feature toggles to mitigate risk, for A/B testing, for canary releases, or for when you plan continuous deployment for your software. If you plan an application where there will be a gradual rollout of new features, then feature toggles allows your team to test those features before releasing them to the public.
You can also use feature toggles in infrastructure scenarios where engineers can use them as a form of circuit breaker so that they can control deployed aspects of a system remotely and identify what works and what doesn’t.
Feature toggles can be extremely useful but at the same time, you need to be sure your team is using them properly. Having a set of guidelines/best practices can ensure that feature toggles are being used properly. You will likely have several such guides in your business, from data lake best practices to communication protocols.
1. Manage the process
Depending on how large your organization is, you need some form of management process that can oversee use of feature toggles. You may choose one of the many specialist management tools on the market, or something more simple such as a database table or a configuration file. Whichever tool is your preference, it has to be a system that is easy to understand.
Part of that management process is ensuring that everyone working on your dev team understands the purposes of feature toggles and how they should be named and used. You should remember that your preferred system is a long term one. So, rather than diving into the deep end, spend some time discussing with your dev team what system is best and how it will work.
2. Simple naming
It can often seem that your software engineers and developers speak an alien language. As management of toggles can become more complex over time, using a simple naming process – in human language – can help others understand what they are used for and can also help prevent your system becoming bloated over time.
If a toggle – and its use – are easier to understand, then the management process can be less untidy, even if you have multiple toggles (some of them outdated). You also have to be aware that turning on one particular feature toggle may then turn on other feature toggles. Remember, the whole idea of feature toggles is to make development easier, so simple naming can make flags easier to find.
Another thing to consider when naming your feature toggles is to clearly identify what each toggle does. Remember, some of these flags may still be in place years later and your team may have changed in that period. Having simple conventions in place can help you and any future members of the dev team ‘remember’ what each does. There are a few types you can consider:
Kill toggle. If your product has any issues in the future, such as overloading issues, then you want a simple way to ‘turn it off’. Kill toggles can achieve this.
Permission toggles. You may want to have some accesses segmented. For example, premium customers may have access to features ordinary users do not. Permission toggles mean you can control access.
Release toggles. If you want to roll out particular parts of your code in preparation for a public release, then release toggles are ideal.
Experiment toggles. A/B testing can be an important aspect of the development process. Experiment toggles means you can segment your ‘test subjects’ into groups that get the different experiences you are testing.
4. Make switching toggles off (or on) easy
The whole idea of using feature toggles is to make the development process easier. Ergo, you should be ensuring that the toggles themselves are easy to turn on or off. You should also remember that use of these toggles may not always be by developers who can write code and language. You may want different teams to have involvement in the development process as a whole.
The different teams that you may want to be able to use feature toggles in their everyday work includes:
Customer support/service. A customer may contact these teams to request that a particular feature is enabled or disabled.
Quality assurance. This team needs to be able to use toggles in order to troubleshoot reported issues or to replicate a specific scenario reported by a customer.
DevOps. Your DevOps team may want quick access to kill toggles if there are problems with your product or if the system is overloading.
5. Clean up regularly
If you have a larger business – or as you grow – then the number of toggles within your systems can quickly grow with you. Carrying out regular housekeeping duties can help clear toggles that are no longer necessary. For example, you may be using release or experiment toggles when developing your product. But once released to the public, these toggles are mostly redundant.
While having these toggles in place can be harmless, it can be messy when you have lots on your system. You can choose to either have your team remove any redundant toggles at the end of the development process or you can schedule regular cleanups to remove them. You also need to remember that some of your team may be working by remote log in and ensure permissions allow this.
6. Avoid interdependency
You should think of each toggle as being a fully-independent component. Interdependence can mean that when more than one toggle is needed to trigger a specific use case, it can cause some conflict with other toggles you are utilizing. Every toggle you use should have a specific purpose, be clearly named as to that purpose, and be independent from other toggles.
This will involve different approaches for different types of toggle. For example, if you are using permission toggles, your developers need to make sure that any code they use is modular so that different features can be activated in differing combinations. When it comes to security testing, ensuring features are independent is crucial.
Of course, different users of any product are going to have different settings. This means that you should instruct your dev team to make the different combinations of toggles clearly visible. You should store information on those combinations in two distinct areas; the user profile in your database and in your analytics system so you can monitor performance.
Having clear visibility of these combinations can help you and your dev team in a number of ways. When a user experiences any issues, it makes it easier to troubleshoot those issues. It can also help with analytics as you can track users’ behaviors who have different settings. Lately, it is a crucial part of any analysis of A/B tests you undertake.
8. Large products/features
With some large products, you will probably be adding to it, either in the form of updates or new features. This can be a risky endeavor but a necessary one when you plan on a product having a long life. Feature toggles means you can test new updates or features to a limited audience to see how well they perform.
Once your dev team has finished creating the new feature, you can first test it internally and then to a small number of external users. Once you are satisfied the functionality is working wll, you can roll it out to all users. Most developers will break this process into a number of smaller steps so they can monitor metrics and performance. Feature toggles help them do this easily.
There is no doubt that using feature toggles can be a great aid when it comes to any sort of product development. Having guidelines that show your staff the best practices when using them is very important and can help avoid delays and mistakes. You should also remember that other staff, ones who may not know coding, will also find feature toggles useful.
If used properly, these toggles can help streamline processes and tasks. If some of the guidelines are not followed – or are forgotten about – then you could find the development process becomes chaotic.
Disclaimer: The author is completely responsible for the content of this article. The opinions expressed are their own and do not represent IEEE’s position nor that of the Computer Society nor its Leadership.