Start from Where You Are

Understanding the current situation you and your team are currently in is a vital skill. In Chapter 6, you learned about the evolution of the Java ecosystem, and the range of options modern developers now have to create applications. You built on this knowledge in Chapter 3 and Chapter 4 by learning how designing adaptive, or “evolutionary,” architectures in combination with the use modern cloud and container technology can greatly increase both throughput and stability of the software delivery process.

A core requirement of modern software developers, especially technical leads, is keeping up-to-date with changes in technology, tooling, and practices. Learning from books, regularly reading blogs, watching online content, and attending conferences are all valuable uses of the essential portion of your time dedicated to continually improving. Only when you combine an understanding of the current situation you and your team are in with the potential possibilities can you most effectively decide on the best course of action to improve both the delivery of valuable software to users and the fun of building systems.

Build on Solid Technical Foundations

Chapters 5 and 6 provided you with foundational skills and tooling around building Java applications. Whereas in the early 2000s you could focus solely on coding Java, the reality is that now you also have to develop skills (or at least an understanding of those skills) that used to be purely within the domain of operations. The rise of the DevOps and SRE approaches to the delivery and running of software have crystallized this.

Chapter 7 built on many of the things you learned about packaging applications for the deployment onto available platforms you explored in Chapter 4. Packaging traditional Java deployment artifacts like the JAR and WAR for standalone execution adds new challenges, as does the use of VM, container, or FaaS technologies. Chapter 8 combined and extended many of the skills you learned over the previous chapters, and shared with you the importance of being able to develop and test locally as effectively as possible.

In Chapters 9 and 10, you began your journey into the early stages of the core of continuous delivery: continuous integration, and deploying and releasing functionality by using a build pipeline.

Continuously Deliver Value (Your Highest Priority)

The first of the 12 principles behind The Manifesto for Agile Software Development states the following:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Continuous delivery is not only the catalyst to enable early and continuous delivery of functionality to customers, but it is also the mechanism in which value (to a large degree) can be verified. Of course, you may not get the required functionality exactly right on the first try—probably far from it—but the framework provided by CD allows you to iterate fast.

Chapter 11 has shown you how to capture value hypotheses and codify user requirements, ideally through BDD-inspired collaboration and processes. With the emergence of container and FaaS technologies, and a whole host of testing harnesses and test double frameworks available to you, the Java ecosystem offers a compelling platform from which teams can deliver valuable software.

As you have seen in Chapter 12, an effective CD pipeline also enables the validation of system-quality attributes, or nonfunctional requirements, and these can be just as important to get right as their functional counterparts. It is vitally important that you take the time to implement these core validation steps within a CD pipeline, and equally crucial that you keep them up-to-date. In the previous chapter, your learned about the capability to “shift left on security,” and the same value can be seen by “shifting” left many nonfunctional verifications, in both the pipeline itself and also in your thinking and designing process.

Once expectations have been codified within a CD pipeline, they can, of course, be automated and run multiple times. This not only provides more reliable results in comparison with the same operations carried out by humans (computers, after all, are great at carrying out repetitive and tedious tasks), but also frees up additional time for human engineers to do what they are good at: be creative, look for improvements, and empathize with the user requirements.

The effort to implement all of these validation steps should be shared throughout the team, as this is often the only way that enough time and energy will be available to work on the CD pipelines, and this is also typically the only way to get buy-in and shared responsibility across the organization. Every single person on the team should be focused on the continuous delivery of valuable software, and the practices on CD itself can often be a catalyst for organizational change.

Increase Shared Responsibility of Software

You have read about the importance of shared responsibility within several of the chapters of this book. The current market dictates that customer requirements change and shift faster than ever before. Technology also changes more rapidly today than ever before, as does the associated security threat landscape.

With the exception of the simplest website, it is clear that no one person can support all of these changes. When you are delivering software as part of a large enterprise, it would be impossible to even gather all of the scope into a single person’s brain. Therefore, you have to embrace shared responsibility, and the CD pipeline is the perfect tool to rally around. As the pipeline captures a large part of the value stream, everyone involved can see the flow of business ideas, software, and functionality.

Two core concepts that you learned about in Chapters 13 and 14 are observability and measurements. Observability enables the monitoring of metrics from applications running in production to allow you to close the feedback loop and increase learning. Measuring continuous delivery outputs, such as lead time and the rate of failure, provide you with the ability to objectively evaluate the progress you are making through the use of continuous delivery as you increase throughput and stability.

Promote Fast Feedback and Experimentation

You learned in Chapter 14 that rapid feedback is vital when working with complex systems—and nearly all software applications are complex, adaptive systems. Continual, rapid, and high-quality feedback provides early opportunities to detect and correct errors. From a developer’s point of view, one of the clear advantages of rapid feedback is the reduced cost in context switching and cognitive overhead of understanding a piece of functionality and the code and configuration that underlies.

The power of fast feedback and experimentation goes much deeper than this. Gene Kim, Kevin Behr, George Spafford, and Mike Orzen have talked extensively about the benefits of Three Ways of DevOps: systems thinking, amplify feedback loops, and the culture of continual experimentation and learning. Figure 15-1 provides an illustration.

Figure 15-1. The Three Ways of DevOps (courtesy of The Phoenix Project by Gene Kim, et al.)

The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department; you read about this previously in regards to increasing shared responsibility. The Second Way is about creating the right-to-left feedback loops, from operations to development, with the goal of shortening and amplifying feedback loops in order for corrections and improvements to be continually made. You’ve learned about this and the need to “shift left” many forms of testing and verification. The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it—both in teams and codified within the build pipeline itself.

The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery. Experimentation and taking risks ensure that you keep pushing to improve, and you need mastery of the skills that can help you recognize and course-correct when you have gone too far into the unknown. The outcomes of the Third Way include allocating time for the improvement of daily work (for example, focusing on improving the build pipeline and associated skills), creating rituals that reward the team for taking risks, and introducing chaos and disaster-recovery testing into the system and team in order to increase resilience.

Expand Continuous Delivery in an Organization

If you are keen to promote continuous delivery throughout your organization, there are two key approaches that you explored in Chapter 14: knowledge sharing and demonstration of benefits.

Knowledge sharing increases awareness of the principles, practices, and technologies associated with CD, such as those contained within The DevOps Handbook and The Phoenix Project. Many interesting presentation recordings from the DevOps Enterprise Summit YouTube playlists contain great stories and insights from thought leaders and practitioners across the industry, many of whom have focused on challenges in implementing the DevOps mindset and practices like CD within large enterprises. The culture in some organizations can be resistant to learning from resources like this, and therefore you may need to subtly introduce this type of knowledge sharing through the use of weekly book club sessions or “brown bag” lunchtimes, where anyone interested can join in and allocate dedicated time to learning.

The demonstration of benefits is also key to increasing adoption of CD principles throughout an organization, and for this to happen, you must become effective at capturing metrics, and at telling a story around these metrics. The starting point is often simply adding basic metrics capture to key processes within an organization, such as the time taken from idea to production, the number of failed deployments or production outages, or the number of bugs caught by automated testing. You can also add metrics to the systems running in production, and capture the number of user sessions, the average CPU and RAM requirements of an application, and the write performance of a data store.

Once you have these metrics in place, you can create a baseline from which you can (hopefully) demonstrate improvement. It is important to track how the metrics change with your attempts to implement CD, and also to attempt to fit a story to the changes. You may not always get this correct, but ideally you can frame the story as a hypothesis, and create tests to validate your ideas. Human beings have evolved alongside storytelling, and this is a powerful mechanism to create buy-in and understanding with people across the business.

Continuous Improvement

In conclusion, you should strive to continuously improve everything you do in creating software and delivery business value to customers. The principles of continuous delivery and the associated practices, like that of the build pipeline, are effective mechanisms for driving this improvement. The Continuous Improvement Kata, taken from the Toyota Way and inspired by the martial arts kata approach to honing skills, is a great resource for helping to fully understand the approach, and codifies a lot of the practices you have learned from reading this book. Figure 15-2 illustrates the Continuous Improvement Kata.

Figure 15-2. The Continuous Improvement Kata

It is key to first understand your challenges. Perhaps you are frequently slowed by failed releases, or you don’t get appropriate requirements from the business. You must then grasp the current condition fully, and work with people across the organization and share responsibility for the potential improvements. After establishing the next target condition and planning with your team, you iterate toward this goal. Along the way, monitor for signs of success and failure, and continually reflect on and feed your learning forward into the process.

This book should act as your guide for implementing continuous delivery and ultimately drive continuous improvement within your organization. Although a book of this scope can never hope to cover every single topic (or every topic in the depth you may require), we are confident that this book can point you in the correct direction and provide a foundation to get started. When you have success and identify new techniques or areas of improvement, please do get in touch, or ideally write an article or book that expands on your idea.

Summary

In this concluding chapter, you have reviewed the core skills that you learned from this book so far, and explored the key ideas behind continuous delivery:

• Understanding the current situation that you and your team are currently in is a vital skill. This must be combined with continually developing your understanding of the possible practices and tooling in order to set goals for continual improvements.

• A core requirement of modern software developers, especially technical leads, is keeping up-to-date with changes in technology, tooling, and practices.

• Whereas in the early 2000s you could focus purely on coding Java, the reality is that now you also have to develop skills (or at least an understanding of those skills) that used to be purely within the domain of operations.

• Continuous delivery is not only the catalyst to enable early and continuous delivery of functionality to customers, but also the mechanism in which value (to a large degree) can be verified.

• Every single member of a software delivery team should be focused on the continuous delivery of valuable software, and the practices of CD itself can often be a catalyst for organizational change.

• Observability enables the monitoring of metrics from applications running in production and allows you to close the feedback loop and increase learning.

• Measuring continuous delivery outputs, such as lead time and the rate of failure, provide you with the ability to objectively evaluate the progress you are making.

• Gene Kim, Kevin Behr, George Spafford, and Mike Orzen have talked extensively about the benefits of Three Ways of DevOps: systems thinking, amplify feedback loops, and the culture of continual experimentation and learning.

• If you are keen to promote continuous delivery throughout your organization, there are two key approaches: knowledge sharing and demonstration of benefits.

• You should strive to continuously improve everything you do when creating software and delivering business value to customers. The Continuous Improvement Kata is a great resource for helping to fully understand the approach.

The end of this chapter also marks the end of this book, but this is the beginning of your journey. We wish you the best of fortune on this journey with continuous delivery!