The process of launching a new feature has changed a lot over the last decade. Ten years ago, a feature launch was commonly tied to code release. This meant that when the release branch was merged into master and pushed to production, new features riding on that branch would be launched to customers. 

RELATED CONTENT: 
Going ‘lights-out’ with DevOps
Feature flags simplify feature development and testing for Dev teams and QA

This all changed with the introduction of feature flags. Feature flags meant that DevOps teams were able to separate code release from new feature launches by putting a new feature behind a flag and then allowing the feature to be slowly released to a certain demographic of users until it was ready to be fully released. The addition of feature flags meant that the flag was able to be completely off, completely on, or partially on (allowing a certain segment or percentage of users to experience the new feature).

This revolutionized the industry, allowing engineers to test the scalability of systems that support the feature and product managers to tie metrics to every feature launch and better track it. But these new possibilities raised some questions. Many DevOps teams were stuck wondering how many steps are required in this ramp and how long they should spend on each step.

The steps taken for a feature launch using a feature flag should be chosen with care. Taking too many steps or taking too long at any step can slow down innovation. Taking big jumps or not spending enough time at each step can lead to suboptimal outcomes. As daunting as this may seem, approaching your feature launch in the following five key phases will help ensure that it runs smoothly. 

The first of these phases is known as the dogfooding phase. The purpose of this phase is to detect any integration bugs, get feedback from team members on the design and feel, ensure that the production gets certified by Quality Assurance, and conduct training for the sales and support team. This step should be quick, as it is not part of the process where performance challenges are identified, or the impact of the feature is measured.

The next phase is the debugging phase. The goal of this phase is to reduce any risk of obvious bugs or bad user experience. Ensure that any UI component renders correctly, and that the system can take the load of the feature. This phase should be conducted via a few quick ramps (i.e. 1 percent, 5 percent, or 10 percent of users) lasting no more than a day, and the focus should not be on the feature impact on user experience but on debugging the feature.

The phase after that is the maximum power ramp (MPR) phase. Once the feature has been debugged and the risks have been significantly reduced, the new goal is decision-making. This is the part of the process where you determine whether or not the new feature is positively impacting the metrics it is supposed to enhance. At this point, you should release the feature to 50 percent of the users; this is the quickest way to collect the customer impact data. 

Next comes the scalability phase. The previous phase should have provided data on whether the feature was successful and, assuming it was, the next step would be to release the feature to all users. However, concerns about the ability of the system to deal with 100 percent of users having access to the new feature may be something to consider. The resolution for this worry about the operational scalability is to increase the release of the feature from 50 percent to 75 percent and leave it there for about one day of peak traffic to ensure confidence that the system will be able to handle the new feature.

The last phase of the feature launch is the learning phase. This phase is to understand the long-term impact of the features on users. For example, if your platform uses advertisements, did the new feature cause long-term ad blindness? The way to address these concerns is by holding back the new feature from 5 percent of the users for about a month. This will enable you to better analyze the long-term impacts and give you time to fix them. 

Overall, remember that the dogfooding phase is for internal feedback, the debugging and scalability phases are meant for risk mitigation, and the MPR and learning phases are meant to speed up learning and decision-making.

The introduction of feature flags has enabled DevOps teams to take more control of the process and significantly reduce the odds of “failed” launches along the way. While feature flags can pose a lot of new questions, implementing these five phases, while having specific objectives for each, will help ensure your launch goes off without a hitch.