This article serves as a checklist for DevOps teams when utilizing feature flags and discusses the top five steps for an issue-free launch.
The last decade has seen the way features are launched change a lot. In 2010, feature launches were mostly linked to code releases; this meant that the release branch was combined with the master and had to be pushed into production. This meant any new features that were on the branch would then be instantly pushed out to users.
The emergence of feature flags changed all of this; it allowed DevOps teams to split the code release from any new feature launches. This was achieved through flags – having a new feature sit behind a flag meant that it could be gradually released to a specific demographic of customers. This meant that the feature could be monitored and then fully released when it was determined to be ready. Feature flags brought about the capability to have the flag switch from off, on, or partially on.
With this introduction, the industry was revolutionized, engineers were now able to experiment with feature supporting systems’ scalability, and product managers could better track feature launches by connecting metrics. But with these new possibilities came new questions – DevOps teams wondered what steps were needed in this ramp, as well as how much time was needed for each step.
Learn More: Fast-Track Your Software Translation and LocalizationOpens a new window
Well, I’m here to give the answer – to start, it is important to take careful consideration when deciding the steps taken for a feature launch using a feature flag. This is because taking an unnecessary amount of steps or taking an elongated time at any step can result in a slow down of innovation. Skipping over steps or not spending enough time on a step can result in suboptimal outcomes. Now this may seem a bit daunting, but if you approach the feature launch with the following five key steps, it will ensure that it runs smoothly:
Dogfooding step
This step is when you discover any bugs in the integration, collect internal reviews on the design and feel, get the production certified by Quality Assurance, and implement training for the sales and the support team. Since this step is not part of the performance challenges identifying process, it should not demand a lot of time.
Debugging step
The purpose of this step is to tackle any obvious bugs and reduce the risk of a bad user experience. Ensure that the system is able to handle the load of the feature and that all UI component renders correctly. It is best practice to implement this step in a few quick ramps (i.e. 1%, 10%, or 15% of users) and it should last no longer than a day.
Maximum Power Ramp (MPR) step
By the time you have got to this step the feature should have been debugged and the risks significantly reduced. The next goal is decision making. This step is where you determine if the new feature is having a positive impact on the metrics is aimed at enhancing. This is when you release the feature to half of the users; this is the quickest way to collect the customer impact data.
Scalability step
Assuming that the data from the previous step determined that the feature was having a positive impact on the metrics, this next step would be when you would release the feature to all users. Doing this may raise concerns about the system’s ability to handle 100% of users having access to the new feature – the solution to this is to increase the release of the feature in another increment, from 50% to 75%. It should remain at 75% for about a day to ensure that there is confidence that the system handling the new feature, especially during peak traffic hours.
Learning step
This step is allows you to gain an understanding of the long-term impact of the feature. For example, has the new feature caused long-term ad blindness (if your feature uses ads)? The way to tackle these concerns is by releasing the feature to only 95% for about a month, holding back from 5%.
Feature flags allowed for DevOps teams to gain more control over the process of releasing a feature. It also significantly reduced the liability of failed launches. While feature flags may have you ask quite a few questions, implementing these five steps, while having specific objectives for each, will help ensure your launch goes off without a hiccup.
Let us know if you liked this article on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!