When I was a software developer long ago, I was always excited about optimizing the platforms, tools, and libraries that enabled writing code, building applications, and deploying them to environments. I started out using Concurrent Versions System and SubVersion for version control, writing makefiles for C++ apps, developing Apache Ant scripts to package Java apps, and writing way too many Unix scripts to automate deployments. Today, Git, Jenkins, and other tools have simplified many essential devops practices, and many organizations consider them necessary software development tools.
A few scaffolding capabilities that we developed back then now have commercial platforms. Feature flagging is one of these, and I believe many organizations either know little about it or only use it in basic ways. That can be a real missed opportunity, especially for companies developing microservices, innovating customer experiences, or modernizing legacy applications.
In 2020, I wrote about ways to drive agile experimentation using feature flags where I focused on how devops teams use them to manage user experience experiments or control deployed capabilities at runtime. Instead of implementing a branching strategy in version control tools, it can be more scalable and manageable to use feature flags to toggle production-ready capabilities on and off.
Feature flagging has a lot more depth than controlling what goes into builds and A/B testing features. After speaking with John Kodumal, CTO and cofounder at LaunchDarkly, I knew I had to follow up with a second article to illustrate where feature flagging capabilities can advance agile development teams, devops practices, and software development capabilities.
Kodumal shares this perspective on why feature flags are important to devops. “While there are endless reasons to use feature flags, the overarching benefit is to reduce risk at scale without compromising speed. No matter how well defined your code may be, errors and unexpected bugs happen. Feature flags allow developers to roll back a change in milliseconds instead of hours or days.”
Here are five use cases that should make you consider putting feature flagging capabilities at the top of your software development capabilities road map.
Provide feature controls to product managers
Feature flags control what code is enabled for which users, but that doesn’t mean the development team has to manage the switches. There are many good reasons why a development team should trust product owners with the keys to decide which features to enable and when.
For example, maybe you’re developing a feature that needs to turn on during a marketing event when the product team announces new capabilities. Do agile developers really want to be tethered to the event and be responsible for turning it on at the right time in the presentation?
Development teams should discuss what flags to hand over to product managers. Doing this is not only practical, it can strengthen trust with business sponsors. Kodumal says, “We are beginning to democratize the release process and put it in the hands of the people making business decisions and not just the engineers that control the rollout.”
Use workflows to toggle features
It’s one thing to hand the steering wheel to the right people to drive the bus. It’s even better when you leverage automation and workflow to control it. Workflows can help ramp up access to a feature when it’s resulting in a positive impact or automatically ramp them down or disable them if they are causing performance or reliability issues.
Workflows can be very powerful when integrated with monitoring tools or AIops platforms that track and correlate incidents to feature flags. Correlated incidents and alerts can then trigger automations to control and toggle features.
Integrate with customer analytics to control segments
Performing A/B tests or running multi-armed bandit algorithms and slowly opening up a feature set to a wider audience is one way to roll out a new capability. The natural extension is to use control segments, such as beta testers or early-adopter groups. For customer-facing applications, product developers and marketers may want to personalize the offering by connecting to customer segments defined in their customer relationship management or customer analytics tools.
Digital experience platforms from top providers such as Adobe, Acquia, and Optimizely offer advanced content management and personalization capabilities that may be optimal choices when developing larger-scale e-commerce solutions, subscription websites, or other omnichannel customer experiences. But for many customer or enterprise applications that require basic personalization or customer segmentation rules, feature flagging and using static or dynamic customer segments to control capabilities may be sufficient.
Keep all stakeholders informed about feature rollouts
You might be tempted to develop feature flagging capabilities yourself; configuration toggles and basic business rules aren’t that complicated to code into your applications. But as I experienced as a developer, it may be difficult to manage and control feature flagging when many flags are created across services, applications, and development teams. I put the bar at 30 flags. More than that begins to accumulate technical debt to document and support them.
Beyond technical debt, the bigger issue is communication. When a user opens a support ticket, does the service desk know what features the dev team enabled in the application and the user who requested help? If there’s a sudden rise in application errors, can the network operations center trace this to a feature that was turned on immediately before the incident?
Connecting feature flags to other IT tools such as GitHub, Jira Software, Splunk, or Slack is one way to broadcast and track configuration changes. For example:
- Other developer teams might need to trace feature flags, the requirements captured in agile user stories, and the underlying code.
- Site reliability engineers can track a Slack channel to stay informed on changes and trace issues from observability data, logs, and monitoring alerts to feature status.
- Trained service desk and customer support teams can also use these tools to research and diagnose user issues.
It’s hard to implement all the integrations with do-it-yourself feature flagging, so although a homegrown approach may be a good start, it likely won’t have all the management and integration capabilities of a commercial offering.
Control the rollout of app modernizations and cloud migrations
Many IT teams are modernizing legacy applications, decoupling monolithic applications into microservices, and migrating applications to public clouds. One of the challenges is knowing whether rearchitected apps are production-ready, especially when many legacy applications do not have robust automated testing or continuous integration and continuous delivery (CI/CD) pipelines to control deployments.
Development teams should use these opportunities to address technical debt, including developing more robust automated and continuous testing. Unfortunately, this isn’t always realistic because of time constraints, access to subject matter experts, or application complexities.
Another option is to add feature flags to control the transition. As LaunchDarkly’s Kodumal says, “You can write tests for years and try to get confidence in the system—and you should invest in testing—but if you’re migrating to something new, feature flags give you an ability to run old and new in parallel. If both systems are behaving the same way, then you can shut traffic to one and be confident in the transition.”
My take is that feature flagging is an essential devops capability, right up there with version control, CI/CD, infrastructure as code, and AIops. For organizations serious about modernizing applications, improving user experiences, and increasing deployment frequencies, developing with feature flags and using feature flagging management tools can improve reliability, flexibility, and personalization options.