Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Re-Thinking Your Development Cycle With Feature Flags

DZone 's Guide to

Re-Thinking Your Development Cycle With Feature Flags

Feature flags remove some of the stress of deployment by making it easy to toggle features on and off.

· DevOps Zone ·
Free Resource

If you’re looking to have your development cycles be more efficient and launch products more safely, here’s three things you should know. Whether it’s releasing a beta of your new feature or controlling feature rollouts, we’ll go over challenges and solutions to help you deliver reliable products faster.

Forget the Standard Development Cycle Philosophy

On launch day, most engineering organizations push a big button to launch a new feature. It’s a scary moment. The new feature might introduce new bugs to existing features or bring down the entire product itself.

It is fairly standard for teams to deploy to staging environments and test before the final push to production because you’re supposed to catch bugs in staging. Everything seems fine with the product you just launched, but it somehow breaks an existing feature. This development cycle of launch-and-wait occurs at companies of all sizes and industries all too often.

If you look at development processes to science experiments, you can’t keep doing the same thing and expect different results. What if you could remove this anxiety of a potentially error-ridden launch by gradually releasing and testing your feature in a real-world environment? The idea of testing in your production environment might seem crazy at first, but if done thoughtfully, it can be extremely impactful to reducing risk.

Tools to Improve Your Deployment Process

Before the rise of feature flags, development teams would launch new features and monitor anxiously for post-launch incidents. Often times, they would scramble to check how the new feature was doing in production and whether or not it broke anything else. This is where feature flags, also known as release toggles or feature switches, come into play.

Feature flags are a software development technique that enables or disables functionality, without deploying new code. This allows for better control and more experimentation over the full lifecycle of features.

Engineers are able to see and understand real product-usage without impacting customers’ experiences when they use feature toggles in a continuous integration or continuous delivery development practice. Once the feature has been thoroughly tested and engineering is ready to deploy to production, they can use a feature rollout to slowly introduce the new feature to a subset of customers. This practice of gradually and stealthily rolling out new features to a percentage of your customer base is known as a canary release.

When you start to control features with incremental rollouts, teams can effectively decrease vulnerabilities by narrowing the pool of customers who interact with new, unproven features. This smaller pool of customers can engage with your new features and provide real usage data so that you can refine before releasing to all customers. If the new feature needs to be rolled back, controlled rollouts enable you to do so without affecting customers or existing features.

Additionally, implementing feature flags within a continuous delivery approach expands your feature management system to include masterful product concepts such as A/B testing and experimentation. Feature flags are the foundation of product experimentation because they serve as underlying levers for driving measurable product impact. When you begin to measure the business impact of all features you’re rolling out, feature flags allow you to more easily conduct product experiments to test the validity of the features as well as to dive into product analytics.

Gain Product Velocity and Customer Confidence Through Visibility

First and foremost, feature flags and controlled rollouts positively affect your development and product teams, codebase, and end users. Rolling out features enables your development team to deliver high-quality products without fear of potentially breaking something and exposing vulnerabilities. In order for feature flags to be effective, they need to be used habitually in an Agile development cycle and at the forefront of all product development. In addition to increasing development confidence, feature flags are helpful for reducing the frustration of merge conflicts. Engineers can collaborate seamlessly because feature flags help fuel more frequent deployments and allow for more transparency in workflow.

From feature launches to bug fixes and performance testing, feature flags enable you to do the heavy lifting behind the scenes without impacting your customers’ experiences. Additionally, companies that use feature flags can embrace the practice of rolling out betas to their premium customers to create an exclusive product-release experience. Feature flags give you full visibility and control over who is using your feature and how they’re using it. With feature flags, you can push betas through faster, increasing product velocity and quality.

Next Steps: Identify Where Feature Flagging Fits In

Start by assessing your current feature management challenges and needs. Thinking through your organization’s use cases will help you scope out the ideal way to implement and maintain a feature flagging system. Start by creating a feature flag for something simple, like a visual feature, and slowly expand to more complex features, like a permissioning system.

If any of this is of interest to you, you can check out Optimizely Rollouts for unlimited feature flags and controlled rollouts as you think about your next feature release. Next, learn how to integrate them into your development cycle and how to reduce technical debt by cleaning up outdated feature flags.

Topics:
development cycle ,feature flags ,continuous integration ,continuous delivery ,a/b testing ,feature toggles ,devops ,canary release

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}