Understanding modern software development

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.