An important concept to understand in DevOps is continuous delivery. You can find a lot of materials on this topic all over the internet. I also typically recommend reading the book "Continuous Delivery". Reliable software releases through build, test and deployment automation by David Farley And Jez Humble. A lot of industry leaders believe, if you can start to introduce the concept of Continuous Delivery into your organization, you will see how challenging it may or may not be to adopt and practice additional DevOps techniques. In this lesson, we're going to start by talking about continuous delivery and the five key principles. By the end of this lesson, you should be able to describe each of the five key principles, as well as provide examples for support. The first key principle is building quality in. As mentioned earlier, this is critical for creating faster feedback loops. In continuous delivery, we invest in building a culture, supported by tools and people, where we can detect any issues quickly so that they can be fixed straight away when they are cheap to detect and resolve. Most organizations have security penetration testing as a final gate before deployment. In my experience that often leads to rework and frustration within the teams, because the feedback comes so late in the lifecycle. In order to build quality in, the aim would be to incorporate security tests early in the deployment pipeline to help avoid late feedback. Teams can address issues early and security teams can also feel confident that the tasks are automated and documented. The second principle is to work in small batches. Organizations tend to plan work in big chunks, whether building new products or services or investing in organizational change. By splitting work up into much smaller chunks that deliver measurable business outcomes quickly for a small part of our target market, we get essential feedback on the work we're doing, so that we can course correct. A key goal of continuous delivery is changing the economics of software delivery process so the cost of pushing out individual changes is very low. At Starbucks, the concept of small batch was challenging for some of the teams. In order to demonstrate what it would mean to send a small batch through the system, the team added a comment to a file and deployed it to production. The results got the team energized about breaking down their work. They had a cycle time of 11 days versus the typical 84. The third principle is that computers perform repetitive tasks, people solve problems. One important strategy to reduce the cost of pushing out changes is to take repetitive work that takes a long time such as regression testing and software deployments and invest in simplifying and automating this work. Thus, we free up people for higher problem-solving work such as improving the design of our systems and processes in response to feedback. As an example, at Nordstrom, the mobile team automated all deployment activities including operating system patching. All repetitive tasks. No one could even log into production. Only the CICD pipeline could access production, this helped to streamline things enormously for team. The fourth principle is to relentlessly pursue continuous improvement. The most important characteristic of high performing teams is that they are never satisfied. They always strive to get better. High-performing teams make improvement part of everybody's daily work. The restaurant POS team at Nordstrom is one of the best examples I've seen of a team relentlessly pursuing continuous improvement. Even after they met the goals originally laid out, they continue to conduct A3 problem-solving and started focusing on the next bottlenecks. The team was energized by this new way of getting work done. Finally, principle five is the idea that everyone is responsible. As we learn from Ron Westerns work, teams working in bureaucratic organizations tend to focus on departmental goals rather than organizational goals. Thus, development focuses on throughput as well as stability, testing, quality and operations. However, in reality, these are all system level outcomes and they can only be achieved by close collaboration between everyone involved in the software delivery process. A key objective for leadership is making the state of the system level outcomes transparent, working with the rest of the organization to set measurable, achievable, time-bound goals for these outcomes and then helping their teams work toward them. Currently at Nike, we are working to align on shared outcomes across teams. For example, my engineering teams are aligning with my peers operations teams on the following outcomes, cycle time, mean time to restore, meantime to detect, the percentage of unplanned work, deployment frequency and employee net promoter score. Again, as you start to analyze your organization's readiness to adopt continuous delivery, you'll see where you need to focus and it's extremely important not to forget the cultural components. A lot of vendors will tell you that they can build continuous delivery for you. However, that won't be a sustainable approach in the long-term. Taking the framework above and focusing on the five principles is a much more effective way to maintain focus and create a true culture of continuous learning.
