What capabilities are needed in a feature flagging platform at different phases of the software delivery lifecycle?
We've written a lot about the build vs. buy decision. If you decided to buy instead of build, what are some of the capabilities you should look for. As a developer, you need to consider how feature flags come into play during the various phases of building a feature—design, coding, testing, and releasing. Think about what the must-have features are and which ones are nice-to-have during each of these phases.
Design phase
We believe you should start thinking about using feature flags at the design phase. The decisions about a feature made during the design phase can help you determine how to configure targeting rules for the feature and how to test and collect feedback on a flag.
1. Broad SDK supportÂ
Parts of your application may be written in different languages. You're going to want a platform that supports all the languages you code in. Having a wide variety of SDKs at your fingertips, in a single platform, helps you choose the best programming language for your features. Don't limit yourself to a single SDK or deploy multiple tools to cover all your SDKs. Â
2. Experimentation
As you are designing a feature, there may be questions about the best way to proceed. What if you ran an experiment to collect evidence instead of trusting your gut? Having data to support a design decision can save hours of work having to refactor code or start over from scratch.Â
When experimenting and designing in general, you need to collaborate with other teams and team members. Sharing information on experiments with product, customer success, or support is an essential part of running a successful experiment. Look at what types of collaboration and access is available to people outside of the development organization.
Build and testing phases
3. Granular targeting rules for developing and testing
When building a feature, you likely want to deploy code to production early but limit access to only yourself or your team. Targeting a single user or group of users based on a variety of attributes gives you the flexibility and peace of mind to deploy code to production early in the development phase to test out the design. You want to be able to test your features in production without releasing the feature to everybody.Â
4. Safety and security
Testing in production can be a scary thing. How do you ensure you aren't making changes to the wrong flag or environment. Feature flags are not only used during the build process. They're also used for operational purposes and to manage entitlements. You need to make sure you can't accidentally disable or change the wrong flag. As a developer, you want administrative access to test, staging, or dev environments, but when it comes to production more restrictions ensure no surprises when a flag is accidentally toggled. There's no need to live in fear if role-based access control (RBAC) grants or restricts access to resources within the flag management platform.Â
And when something does go wrong, you need detailed audit logs to see what changes were made and by who for a given environment. Audit logs can help you quickly identify whether a recent flag change resulted in unexpected behavior.
Release phase
5. Targeted and percentage-based releases
Not all features release to production in the same way. Some features target specific groups of users; others can be released more broadly. You need the flexibility to release features in a variety of ways. For example, if you're rolling out a new currency conversion feature, you want to target users in select countries. But, if you're releasing a new home page, you may choose to release to a percentage of all users. And speaking of targeting, you want the ability to target users based on multiple attributes, either pre-defined or custom.Â
6. Schedule release progression
Releases may not always happen when convenient to your schedule based on time zones or scheduled time off. Scheduling changes to targeting rules for future dates and times means you don't have to plan your day/week/life around a scheduled release.
7. Automatically disable a flag
Releases don't always go smoothly, sometimes things fail. When a failure occurs, you want to limit the blast radius and get that feature turned off as quickly as possible. When monitoring and observability systems detect that critical thresholds have been passed, you shouldn't have to wait for a person to disable the flag. Integrations with observability and monitoring tools to automatically trigger a flag upon an alert can stop a situation from impacting more users.Â
Launched
A feature isn't done until the code for the feature flag has been removed. Nobody likes it when technical debt accumulates. Look to see what functionality exists to help you identify and remove flag code from launched features.
8. Filter relevant flags to reduce the accumulation of technical debt
If your company has many flags, you need a way to quickly filter through and find relevant flags when addressing technical debt. Filtering all flags by status, you can see which flags have not rolled out to all users, which flags are permanent, and which flags can be safely removed.
9. Configure Slack remindersÂ
One way to make sure flags don't build up in your codebase is to get reminders and notifications sent to the tools you use regularly. Having your feature flag platform send you a message when a flag's status becomes launched or inactive provides a helpful reminder to remove the flag.Â
10. Find all flag references in your codebaseÂ
Knowing a flag needs to be removed isn't the same as remembering all the files that reference the flag. Ensure you can integrate your flag platform with your code repository to see which files refer to a flag quickly. With this, you won't accidentally miss a file containing a reference to a flag.
No matter the size of your team, or where you are in your DevOps journey, there is a lot to be considered when choosing the right feature management platform.
This list can help you make an informed decision and make sure you don't forget critical aspects.Â
To learn more about feature management for developers, check out our recent post, Build: The First Pillar of Feature Management.Â
Â
.webp)
