Where does feature management come from?

I will explain what feature management is in detail in the next chapter, but before that, I will talk broadly about how this approach can be applied to a modern DevOps way of working and how it fits within the DevOps life cycle. The idea of feature management in modern systems is self-explanatory – it is an approach to being able to manipulate components within a production system without performing any deployments. This change can be achieved safely and easily, without the need to change or release an application's code.

As we will see throughout this book, feature management can be used in several ways within systems to offer new ways of building and developing software. These include the following:

• Progressive rollouts: To deliver a new implementation to a production system
• Experiments: To gain insight into which variation of a feature performs best
• Switches: To use permanent feature flags within an application to turn non-essential pieces of functionality on or off
• Migrations: To safely move from one system to another

Now, let's look back over the key phases of the DevOps life cycle. Here, I will explain how they can be changed and improved by introducing feature management and its various implementations and use cases.

Revisiting the DevOps life cycle

Let's look at how feature management can be employed within the DevOps life cycle to improve the way software is built and delivered:

• Planning: With feature management, smaller amendments to an application can be considered as they can be quickly accessed to understand their value before larger and more expensive work is carried out. Feature management also allows for more risky ideas to be considered since any potential risks to production systems are reduced. All of this allows for an improved planning stage.
• Developing: Developing new features can be undertaken more safely with feature management as a new implementation can be built alongside an existing one and encapsulated within a feature flag code block (more on this soon). This will allow the feature flag to be used as a toggle and during testing, this can enable a granular approach to discovering where any quality issues might lie. With the ability to switch between old and new implementations, there is less risk of degrading the production system with the work being carried out. It is important to note that this does not mean that quality can be sacrificed to build new, substandard features encapsulated by a feature flag.
• Delivering: When in this phase, the value of feature management becomes most apparent as a feature can be turned on or off with a high degree of precision. Crucially, this reduces the risk of deployments to the production systems as features can be deployed but not turned on for users. A release no longer needs to change the customer experience, even though new functionality has been deployed. Now, with feature management, it is up to the team to decide when and to whom the feature should be enabled, with no release required to make this happen. The flexibility here around the scenarios in which a feature can be enabled is what I will be spending time discussing throughout the remaining chapters.
• Operating: Even when in the operating phase, feature management adds value as the entire health of the production environment can be improved with the ability to turn features off and on in real time. There are several cases where this can be useful, especially when you can turn performance-intensive features off when experiencing high load or when routing requests through different systems.

Revisiting the four key DevOps metrics

Building on the understanding of how feature management can be used practically, I want to explain how it can positively impact the four key DevOps metrics I mentioned earlier:

• Deployment Frequency: Feature management can assist in achieving a better score here as the feature ideas and implementations can now be smaller, making it easier for multiple deployments to happen. In addition, the risk of these deployments is reduced by having the new features turned off when they are released to production.
• Lead Time For Changes: Similar to Deployment Frequency, a team's performance can be improved by delivering smaller pieces of work and mitigating risk, allowing for quicker releases. There is also the option to bypass some testing environments and processes with feature management, which can save a good deal of time – we will get to this topic in Chapter 7, Trunk-Based Development, where I will explain this in more detail.
• Time To Restore Service: With the ability to turn features on and off with the flick of a button, feature management enables rapid responses to service incidents. This could be turning off a frontend feature to routing requests to a different backend service.
• Change Failure Rate: With feature management, teams can keep the change failure rate very close to 0. As we mentioned previously, if features and changes are deployed to production with the feature flag turned off, then the chance of an issue within production is minimal. Rather, the impact might occur once the feature is turned on, but the blast radius can be far smaller and better managed through targeting which users will be served the feature. Turning a feature off that is causing a problem during an incident can resolve an incident immediately. This allows you to find a real fix for the problem feature to be implemented in a less pressured manner.

From these basic examples, I hope you have a good sense of how feature management can help improve how software can be built and delivered, and some of the ways that its impact can be measured. Throughout this book, we will learn more about the value it can bring to teams and businesses.