Recent years have seen the move to a more modern approach to software development, with DevOps being increasingly used across many industries. DevOps is best described by Microsoft as the union of people, processes, and technology to continually provide value to customers.

DevOps has ushered in the era of working where teams are more empowered than ever before, with ownership across the whole development life cycle of both code and products. This includes managing the production environment, previously the domain of the Operations team. The annual State of DevOps Report (available in the Further reading section; registration is required) shows that teams adopting DevOps are delivering higher quality code faster and more reliably than ever before.

While there are other approaches to working with software, DevOps is perhaps the most popular and has proven success. I will assume that this approach is how you are building and deploying software too. Before explaining feature management or even getting started with LaunchDarkly, I want to share a brief overview of DevOps to highlight where feature management can really add value.

Introducing the DevOps life cycle

DevOps is not just a practice of writing code but a comprehensive approach to defining, designing, and delivering software. It can be defined into four key areas within the application life cycle: planning, developing, delivering, and operating. I will describe these areas within the context of where feature management can be factored in later:

• Planning: Within this stage, the team works to understand the problems to solve, reviews the available data, and creates ideas and plans for features to improve their system and to add more value for their customers.
• Developing: In this stage, the features are implemented and checked against quality measures to ensure that the planned feature will work to deliver the expected functionality.
• Delivering: When in the delivering phase, the implemented feature goes through the build and release pipelines, ultimately to be deployed to the production environment to realize the expected value. Ideally, the release process uses CI/CD pipelines and is automated to an extent that is possible. These pipelines can often deploy the feature to several environments before it's deployed to production to validate that the system remains functional with no regressions.
• Operating: Once the feature is in production, it needs to be monitored and the data needs to be analyzed to ensure that the feature works as expected and delivers the planned value. This requires a mature implementation of monitoring, with the team also relying on this data to alert them to issues before they impact the customers. At this point, the data can be used as feedback in the planning phase to allow the team to identify new features and work to deliver additional value.

The aforementioned phases of the DevOps life cycle are highly effective at improving the processes of software delivery but aren't the whole practice of DevOps. Next, we will look at the culture that needs to go alongside these stages to make DevOps truly effective.

Introducing the DevOps culture

Successfully adopting a good DevOps practice is more than just following processes and procedures. It is also about adopting a culture that allows constant improvements to be made to the methodology. Microsoft defines the DevOps culture as having four key areas (available in the Further reading section). Again, I will explain only the areas that come within the scope of feature management:

• Collaboration, visibility, and alignment: For teams to be successful, they must be able to collaborate and communicate well to better understand and define problems and plan effective features and solutions. For teams to be able to trust one another, there needs to be an alignment of timelines and good transparency and visibility of the progress of the work being undertaken.
• Shifts in scope and accountability: I touched on this in the DevOps life cycle overview, where I stated that accountability and ownership must lie with the development teams. Often, this requires a shift from the traditional approach where developers, QA, and the Operations teams work separately to one where development teams are responsible for writing, testing, and deploying a system, along with running it in production. This allows teams to take a holistic view of the problem and solution and achieve the most value for their customers.
• Shorter release cycles: Being able to release new features faster is crucial in being able to iterate and gain more value quickly. It also reduces risks and improves stability throughout the whole DevOps life cycle. This encompasses all aspects of DevOps, from planning through to operating.
• Continuous learning: A growth mindset is the key to an effective DevOps workflow as it allows teams to question everything and learn what works best for their business and customers. This requires an appetite to fail fast and learn from those failures, which helps to improve the systems and processes so that you gain the most value from them. This is possibly the most important aspect of DevOps as without this, the entire DevOps life cycle breaks down. Without this, constant improvement and growth can not be achieved.

Next, we look into the four key DevOps metrics.

Introducing the four key DevOps metrics

It is important to understand that a common way to measure how mature a team's DevOps practice is is with the four key metrics of DevOps (these are defined in State of DevOps 2019, which is available in the Further reading section):

• Deployment Frequency: This measures how often deployments can be conducted. The ideal value for this metric is to be able to deploy on demand and multiple times a day.
• Lead Time to Change: This measure looks at how long it takes for a change to go from committed code to the production system. The target time is less than 1 day.
• Time to Restore Service: It is important to recover from a service incident quickly. A mature DevOps team should be able to recover from a production issue in less than an hour. This metric allows a team to see the average time it takes to restore normal services.
• Change Failure Rate: This measures the number of deployments that have an undesired impact on the production system. The accepted percentage of releases that result in a degraded service for a mature DevOps team is between 0 – 15% of releases.

The best performing teams achieve their reliable results by following both the DevOps life cycle and by having a good DevOps culture.

By using DevOps, software teams and companies have transformed how effective they are, but this practice alone does not solve problems, nor does it limit how new ideas can make this even more effective. One way in which DevOps can be enhanced further is with the ability to manage features within systems and applications, which we will look at in the next section. We will also examine how feature management can positively impact the four key DevOps metrics.

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.

With feature management, having its biggest impact within the delivering stage of the DevOps life cycle and with the expectation that most people are adopting CI/CD pipelines, I wanted to share a few things before we move on and look at feature management and LaunchDarkly.

I want to make it clear that feature management is not a replacement for good CI/CD processes – it is an enhancement of the CI/CD process that offers more control and opportunities to teams.

For some, the idea of changing features within a production system might seem to go against the merits of a good CI/CD pipeline, in that to get a deployment to the production environment, it must go through several quality gates before it is deemed good enough to be released. But, once in production, that system could be changed, and that leads to the question, if a release to production could change once deployed, do the quality gates matter so much? The quality gates do matter and are just as valuable as they would be without feature management. However, the difference is that all possible configurations of the service should be tested within those quality gates before a feature is deemed to be ready for customers. The ability to test all these variations provides the reassurance that whether a feature is on or off, your service will continue to work as expected.

As we will see throughout this book, feature management is not an end itself, but a means to an end. By implementing feature management within CI/CD processes, new opportunities will present themselves, such as the following:

• Testing in Production: This is where a new implementation can be evaluated against a current feature. By using data directly from customers, the new implementation can be proven to be more valuable before it is rolled out to all customers. This covers several topics we will explore, such as rollouts, experimentations, and switches.
• Trunk-Based Development: In this case, production can become the only environment for testing, which speeds up development time and reduces the cost of maintaining multiple production-like environments.
• Infrastructure Migrations: This is where large migrations can be carried out safely and in a methodical manner, even if some parts of a system should be migrated but other parts remain on the existing implementations.

These methodologies and processes can be implemented in other ways but adopting feature management can offer them all within one approach.

This chapter has given you an introduction to the modern approach to building software and how this can be achieved and measured. We have explored several approaches in which feature management can develop those practices and the tangible ways it can improve CI/CD pipelines and DevOps metrics.

With this knowledge, you should be able to appreciate how feature management can be valuable to the software development process. This, in turn, allows teams to benefit from more efficient practices and from building products with increased value for their customers and their business.

In the next chapter, I will explain how you can build on the DevOps methodology to building software, how you can get the most from feature management, and how you can use LaunchDarkly to make it happen.

To learn more about what was covered in this chapter, take a look at the following resources:

• State of DevOps Report 2019, by DORA (DevOps Research & Assessment) – available at https://www.devops-research.com/research.html#reports
• What is DevOps?, by Microsoft – available at https://azure.microsoft.com/en-gb/overview/what-is-devops/#culture