This article explains how to successfully test and deploy using DevCycle’s feature flags.
DevCycle’s feature flags allow companies to continuously deliver and deploy software to their users faster, and more frequently. They also enable teams to perform gradual rollouts, validate their features earlier on, and fix bugs in the code without redeploying.
The idea behind feature flags is to build conditional feature branches into code in order to make logic available only to certain groups of users at a time. If the flag is “on,” new code is executed, if the flag is “off,” the code is skipped, and thus, users will not see the feature.
A feature flag is a software development process used to enable or disable functionality without deploying code. You can wrap a feature in a flag and deploy it to production without making it visible to all users. Once the flag is in production, you can give test engineers or software engineers access to run tests. For this reason, feature flags are a critical element to safely testing in production.
With DevCycle's feature flags, you don’t need multiple environments and complicated routing configurations. You can expose the new code in production only to a small subset of users designated for QA & UAT testing until the testing phase is done, while everyone else can simply use the application as it was without the new code exposed within your main production environment.
For instance, you can deploy a new feature to production without exposing any end users to it by simply setting the targeting rule off in the feature flag production environment.
Once the feature has successfully met all performance requirements and you’re confident that the functionality is working, you can release the feature to a larger audience by updating the audience feature flag target rule definition. You can have this rule set to “All Users” to release the feature to your entire user base at once, or you can choose to gradually roll the feature out to users for additional validation and confidence.
After that, when the new feature is served and consumed by users with success, you can remove the feature flag, both in code and from your DevCycle feature management page.
And that’s how to successfully test and deploy using DevCycle’s feature flags!
Testing in production means having the ability to have real users test real features, with real data, in a real environment. Our most successful clients are able to deploy to production multiple times per day because they have empowered their QA and UAT teams to validate functionality in a real production environment before releasing it to their entire user base.
When QA or UAT reveals a bug, there is no impact on any other users and there is no need to do a full rollback.
This is the real power of DevCycle's feature flags. Of course, you’ll never be able to find every bug in your software no matter how much automated testing you do. But having the ability to turn a feature flag off when you find a bug in production in real-time is like a safety net that gives you the confidence to ship features to users more frequently.
Production testing can be risky, but you can minimize your risk in two ways. First, take advantage of test automation. Don’t bypass running tests in staging\pre-prod just because you will be testing in production. Second, ensure you have the right processes in place to support testing in production, including the use of feature flags.
Testing in production is not a replacement for other types of testing and is not a way to eliminate your QA team. Your staging\pre-prod environment will not 100% match your production environment. While there are many types of tests that you should run in test environments prior to deploying code, you should always test in production for the most accurate data.
Your test suite should include the following types of tests in a pre-production environment before releasing new features:
With DevCycle’s feature flags, you can take advantage of the targeting rules definition to specify which audience should see the new feature. For testing purposes, it might be useful to create some “testing personas” that you use in your end-to-end tests. You can achieve this by ensuring that your user object contains valid attributes that will be evaluated by the DevCycle SDK.
On the DevCycle Dashboard, for your project, go to the "Feature Management" page and create a feature named “Feature Release”
Define the following variable and values for Variation On:
And Variation Off:
Let’s suppose we are using the production environment for which we define the following Target Rule:
On your js-sdk react example app:
1. Define the secret production environment client key in .env file. For instance
NX_CLIENT_KEY= DVC_KEY
2. Make sure you perform all necessary settings on your js-sdk react example app
When targeting in production is OFF:
The SDK will show default values:
When targeting in production is ON and you serve Variation On:
The SDK will show the Variation On:
When targeting in production is ON and you serve Variation Off:
The SDK will show the Variation Off:
That’s all it takes to successfully test and deploy using DevCycle’s feature flags. Create your DevCycle account here to improve your testing processes and release with greater confidence today!
Join the Ship It Club to receive updates on development trends, productivity tips, and gain early access to DevCycle events and giveaways, shipped once a month.
.png)
.svg)
.png)
.png)
