DevOps Adoption Strategies: Principles, Processes, Tools, and Trends E-Book

Martyn Coupland

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch
• Veröffentlichungsjahr: 2021

Seitenzahl: 335

Beschreibung

DevOps is a set of best practices enabling operations and development teams to work together to produce higher-quality work and, among other things, quicker releases. This book helps you to understand the fundamentals needed to get started with DevOps, and prepares you to start deploying technical tools confidently.
You will start by learning the key steps for implementing successful DevOps transformations. The book will help you to understand how aspects of culture, people, and process are all connected, and that without any one of these elements DevOps is unlikely to be successful. As you make progress, you will discover how to measure and quantify the success of DevOps in your organization, along with exploring the pros and cons of the main tooling involved in DevOps. In the concluding chapters, you will learn about the latest trends in DevOps and find out how the tooling changes when you work with these specialties.
By the end of this DevOps book, you will have gained a clear understanding of the connection between culture, people, and processes within DevOps, and learned why all three are critically important.

Leseprobe

DevOps Adoption Strategies: Principles, Processes, Tools, and Trends

Embracing DevOps through effective culture, people, and processes

Martyn Coupland

BIRMINGHAM—MUMBAI

DevOps Adoption Strategies: Principles, Processes, Tools, and Trends

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Wilson D'souza

Publishing Product Manager: Rahul Nair

Senior Editor: Sangeeta Purkayastha

Content Development Editor: Nihar Kapadia

Technical Editor: Shruthi Shetty

Copy Editor: Safis Editing

Project Coordinator: Shagun Saini

Proofreader: Safis Editing

Indexer: Vinayak Purushotham

Production Designer: Nilesh Mohite

First published: July 2021

Production reference: 1100621

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80107-632-6

www.packt.com

Contributors

About the author

Martyn Coupland is the head of DevOps at Transparity, a UK-managed service provider of Microsoft Azure and modern workplace services. He is responsible for the cloud management platform product and the development of DevOps within the organization. Martyn is a Microsoft MVP, a Microsoft Certified Trainer, and a DevOps Ambassador for the DevOps Institute.

About the reviewers

Deb Bhattacharya applies Agile and DevOps to make organizations more successful. Over 20 years, Deb has helped over 50 teams across 4 countries to be more Agile and to be more DevOps. Deb is passionate about that.

Deb's other passion is sports. When Deb was younger, he used to play professional Table Tennis. He won many tournaments, but most importantly, he coached tournament-winning table tennis teams. Deb still plays Table Tennis at club level.

Deb uses all his experience from his hands-on software development background and his sports background to transform teams to Agile and DevOps. The two passions nicely come together here.

I am thankful to Anand Athani, my delivery manager from some 20 years ago, when I was an engineering lead. I was writing the thesis for my master's and Anand suggested that I picked up Rational Unified Process (RUP). That was the beginning of my Agile journey. This learning and contribution is still going on.

James Wasson is currently the platform services engineering lead at Enable Midstream Partners and is a certified DevOps leader. In addition, he serves as an Ambassador for the DevOps Institute. James has spent his career looking for ways to eliminate bottlenecks and increase flow using value stream mapping, automation platforms, and infrastructure as code. His background includes assisting and leading digital transformations at financial institutions, healthcare providers, education providers, and oil and gas providers.

Table of Contents

Preface

Section 1: Principles of DevOps and Agile

Chapter 1: Introducing DevOps and Agile

Exploring the goals of DevOps

Deployment frequency

Faster time to market

Lower failure rates

Shorter lead times

Improved recovery time

Values associated with DevOps

Challenges solved by DevOps

Addressing these challenges

Phases of DevOps maturity

Waterfall

Continuous integration

Continuous delivery

Continuous deployment

How does Agile play a part in DevOps?

The Agile manifesto

Do Agile and DevOps work together?

Agile is more than Scrum

Dealing with unplanned work

What is Scrum?

Kanban

Kanplan

Mixing methodologies within organizations

Scaling Agile teams

Summary

Chapter 2: Business Benefits, Team Topologies, and Pitfalls of DevOps

Key business benefits of DevOps

CX

Business growth

Cost savings

Boost in productivity

Improved employee retention

Better-quality products

Higher customer satisfaction

Improved operational and process efficiency

Transformation topologies

Development and operations collaboration

Shared operations

DevOps as a service

DevOps advocacy

SRE

Container driven

Transformation anti-patterns

Development and operations silos

DevOps team silo

Development does not need operations

DevOps as a tooling team

Glorified SysAdmin

Operations embedded in development

Avoiding failed transformation projects

Rooting DevOps initiatives within customer values

Management of organizational change

Failing to collaborate

Failing to adopt an iterative approach

Management of expectations in terms of DevOps initiatives

Decoding failed DevOps transformation

Summary

Questions

Chapter 3: Measuring the Success of DevOps

Common metrics used to measure success

Common velocity metrics

Common quality metrics

Common stability metrics

Designing metrics for your team

Scenario 1: Small organization with a dedicated DevOps team

Scenario 2: Medium organization with advocacy team

Scenario 3: Large organization with numerous DevOps teams

Scenario 4: Small organization with outsourced DevOps team

Creating rollups at an organizational level

Reporting when multiple teams work on one product

Reporting when multiple teams work on multiple products

Creating goals that are S.M.A.R.T

Summary

Section 2: Developing and Building a Successful DevOps Culture

Chapter 4: Building a DevOps Culture and Breaking Down Silos

What is a DevOps culture?

Roles and responsibilities workshop

Rules of engagement

Retrospectives

Why is culture important?

Increasing transparency

Better communication

Collaboration across teams

Maintaining a strong culture

Starters and leavers

Pushing too hard for success

Lack of innovation

Cultural differences

Lack of buy-in

Breaking down silos in your organization

Creating one vision for team collaboration

Working toward common goals with collaboration tools

Educating together, working together, and training together

Communicating often

Evaluating team compensation

Summary

Questions

Chapter 5: Avoiding Cultural Anti-Patterns in DevOps

Organizational alignment

Resistance to change

Understanding the roles of organizational change

Organizational change process steps

Overcoming resistance

Breakdown in communication

Difficulty scaling up

Start with small teams

Encouraging skill development

Prioritizing culture

Continuous feedback

Automation

Excessively focusing on tooling

How much automation is too much?

Legacy infrastructure and systems

Legacy modernization

Summary

Questions

Section 3: Driving Change and Maturing Your Processes

Chapter 6: Driving Process Change with Value Stream Maps

Understanding value stream mapping

Going beyond DevOps for process improvement

Taking a look at value stream mapping diagrams

How does value stream mapping help?

Challenges of value stream mapping

Use cases of value stream mapping

Identifying and reducing waste

Analyzing differences between process maps and value stream maps

Which should I use?

Explaining an example value stream map

Creating a value stream map

Current state value stream map

Future state value stream map

Summary

Questions

Chapter 7: Delivering Process Change in Your Organization

Eight steps for effective change

Identifying what will be improved

Presenting a business case to stakeholders

Planning for change

Identifying resources and data for evaluation

Communicating

Evaluating resistance, dependencies, and risk

Celebrating success

Continuously improving

Models for business change

Kotter's change management model

Rogers' technology adoption curve

The ADKAR model

The EASIER model

People effects of process change

Direct impact

Indirect impact

The common challenges of process change

Summary

Questions

Chapter 8: Continuous Improvement of Processes

What is continuous improvement and feedback?

Building a continuous improvement culture

Understanding and implementing Kaizen principles

Building a continuous feedback culture

Techniques for continuous improvement and feedback

Continuous improvement processes

Additional continuous improvement techniques

The continuous feedback process

Additional continuous feedback techniques

Iterating changes to processes

Iterative design processes

Using iterative design

Benefits of iterative design

Keeping pace with change

Effective communication

Knowledge transfer

Access to subject matter experts

Summary

Questions

Section 4: Implementing and Deploying DevOps Tools

Chapter 9: Understanding the Technical Stack for DevOps

What are the families of DevOps tools?

Collaborating

Building

Testing

Deploying

Running

How does tooling help the adoption of DevOps?

Choosing tools that facilitate collaboration

Using tools that enhance communication

Lean toward tools with APIs

Always encouraging learning

Avoiding environment-specific tools

Understanding the benefits of DevOps tooling

Increasing code and deployment velocity

Reduction of time to market for new products and features

Decrease in the failure rate of new releases

Improving the mean time to resolution

Improvement in reliability metrics

Eliminating high levels of work in progress and technical debt

Understanding the obstacles of DevOps tooling

Lack of definition of DevOps outcomes

Inadequate knowledge of tooling

Evaluation of tools

The volume of tools available on the market

Lack of tool integration

Summary

Questions

Chapter 10: Developing a Strategy for Implementing Tooling

Understanding architectural and security requirements

Why is enterprise architecture important?

Why is information security important?

Understanding architectural requirements

Developing training plans to help your team

Why are training plans important?

How to develop training plans for your teams

Defining owners and processes for tooling

Identifying the owners of tools in your organization

Mapping processes to tools

Making tooling part of process improvement

Summary

Questions

Chapter 11: Keeping Up with Key DevOps Trends

What is XOps?

Where did XOps begin?

Understanding the XOps landscape

Approach to XOps

Understanding the DataOps ecosystem

Understanding processes involved in DataOps

Understanding tools involved in DataOps

Understanding the DevSecOps ecosystem

Understanding processes involved in DevSecOps

Understanding tools involved in DevSecOps

Understanding the GitOps ecosystem

Understanding processes involved in GitOps

Understanding tools involved in GitOps

Summary

Questions

Chapter 12: Implementing DevOps in a Real-World Organization

Understanding why organizations move to DevOps

Technical benefits

Cultural benefits

Balancing stability against new features

Increased effectiveness

Defining our fictional organization

Current operating model

Challenges that exist within the current model

Goals for the future

Walk-through of DevOps transformation

Having initial planning workshops

Establishing a DevOps Center of Excellence

Setting up governance of the transformation

Establishing an intake process

Identifying and initiating pilots

Assessment of current capabilities

Performing transformation exercises

Scaling out the DevOps transformation

Summary

Why subscribe?

Other Books You May Enjoy

Preface

Every organization wants to adopt DevOps and as an IT professional, it is important to understand the fundamentals of DevOps and how it can contribute to the success of your organization. This book provides complete coverage of the steps needed to implement the culture, people, and process aspects of DevOps.

Who this book is for

This book is for IT professionals such as support engineers and systems engineers and developers who are looking to learn DevOps and for those who are going through DevOps transformation. General knowledge of IT and business processes will be helpful. If you are in a business or service role within IT, such as service delivery management, this book will also be useful for you.

What this book covers

Chapter 1, Introducing DevOps and Agile, introduces the concepts of DevOps and Agile, explaining what DevOps sets out to achieve and how Agile plays a part in DevOps.

Chapter 2, Business Benefits, Team Topologies, and Pitfalls of DevOps, demonstrates the benefits of DevOps and looks at the team topologies used for DevOps adoption.

Chapter 3, Measuring the Success of DevOps, shows how to use metrics to measure success in DevOps and use the correct metrics for the right scenario.

Chapter 4, Building a DevOps Culture and Breaking Down Silos, examines the culture of DevOps in more detail and looks at how to build a successful culture and break down organizational silos.

Chapter 5, Avoiding Cultural Anti-Patterns in DevOps, covers the challenges of building a DevOps culture.

Chapter 6, Driving Process Change with Value Stream Maps, goes into what value stream maps are and how to use them in your organization.

Chapter 7, Delivering Process Change in Your Organization, looks at how to manage and deliver process change in your organization in order to be successful.

Chapter 8, Continuous Improvement of Processes, introduces techniques for continuous feedback and how to iterate process changes.

Chapter 9, Understanding the Technical Stack for DevOps, looks at the pros and cons of the DevOps toolchain.

Chapter 10, Developing a Strategy for Implementing Tooling, shows how to develop an effective strategy for implementing tooling and addressing the training needs of your organization.

Chapter 11, Keeping Up with Key DevOps Trends, explores the latest XOps trends and their relationship to DevOps.

Chapter 12, Implementing DevOps in a Real-World Organization, puts together everything we have learned to look at the implementation of DevOps in the real world.

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: http://www.packtpub.com/sites/default/files/downloads/9781801076326_ColorImages.pdf.

Conventions used

The following text convention is used throughout the book.

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Reviews

Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!

For more information about Packt, please visit packt.com.

Section 1: Principles of DevOps and Agile

In this section, you will gain a working understanding of the basics involved in DevOps, including the benefits, pitfalls, and tooling.

This part of the book comprises the following chapters:

Chapter 1, Introducing DevOps and AgileChapter 2, Business Benefits, Team Topologies, and the Pitfalls of DevOpsChapter 3, Measuring the Success of DevOps

Chapter 1: Introducing DevOps and Agile

In this chapter, we'll introduce DevOps and Agile. We'll explore a few questions, including What does DevOps set out to achieve?, and How does Agile play a part in DevOps?. We'll also explore the values of a successful DevOps transformation and the challenges that DevOps solves for organizations. We will also learn how to build the four phases of DevOps maturity.

In this chapter, we're going to cover the following main topics:

Exploring the goals of DevOpsValues associated with DevOpsChallenges solved by DevOpsPhases of DevOps maturityHow does Agile play a part in DevOps?

Exploring the goals of DevOps

The subject of DevOps is one that tends to prompt many different opinions on what it means and exactly how you do DevOps within your organization. The goals of DevOps and what it helps you achieve within your organization is also something that you will get different answers for from different people, depending on their experience, the industry they work in, and how successful those organizations have been at adopting DevOps.

For many organizations, you can define the following common goals of DevOps. These are goals that apply to most organizations:

Deployment frequencyFaster time to marketLower failure ratesShorter lead timesImproved recovery time

Of course, your organization may be driven by different reasons and even for similar organizations, I would expect their goals to be slightly different. After all, while most organizations share the same challenges, how these challenges can be addresses and which of these challenges will result in the biggest gain in value will also differ, depending on the organization.

Deployment frequency

Improving the frequency at which you release or deploy software in your organization is often a key driver of the adoption of DevOps. We must start to change the way we collaborate and communicate within our organization to deliver value to our end users.

When developers and operations teams start focusing on the same shared goals, they start working together more effectively and deliver better value.

Faster time to market

Most organizations will compete with another for the services they provide. Having a faster time to market gives you a competitive edge over your competitors. With DevOps, you can work to increase value by reducing the amount of time it takes from idea inception to product release.

As a business, your value degrades the longer it takes you to release features to your product and the quicker your competition can get ahead of you. So, achieving a faster time to market is a key goal of not just DevOps but the business as well.

Lower failure rates

Every organization has failures, but with DevOps, you can, over time, expect to realize lower failure rates through teams collaborating with each other and communicating better with each other.

Tip

Cross-functional in DevOps denotes where people from different areas work together in one team.

DevOps gives teams the ability to work more closely and communicate more effectively. In mature organizations, it allows for cross-functional teams. The shared knowledge between these teams and the individuals within them and the greater understanding of each other's roles leads to lower failure rates.

Shorter lead times

Lead time is the amount of time between the initiation and completion of a specific task. In DevOps, this would be the amount of time between work starting on a user story and that story making it to release.

Tied hand in hand with faster time to market, shorter lead times is not just about your product but everything in the whole life cycle. This could be anything from planning where you capture requirements more effectively all the way to building infrastructure quicker than before.

Through slick processes, effective communication and collaboration, and high levels of automation, the lead times throughout your cycle will be quicker, leading to high performance within your team.

Improved recovery time

Of course, we all know that most organizations have Service-Level Agreements (SLAs) to measure the performance of key service-based metrics such as availability. However, how many organizations can tell you, on average, how long it takes to recover a service? Not many.

Having the level of collaboration that lets you discuss the reasons behind failures, understand them, and implement steps to prevent them from happening again is a sign of a mature organization. An organization that measures this metrics and takes steps to reduce them is an even more mature organization.

Downtime is lost revenue and reputational damage to your organization, so reducing that level of downtime is very important.

In this section, we have explored what the key goals of DevOps are and the business value behind the adoption of DevOps. Next, we'll take this further by looking at the values that make DevOps successful.

Values associated with DevOps

DevOps can be split into various pillars when it comes to transformation. That being said, if you wanted to take a high-level view of DevOps rather than one at a deeper level, you can talk about DevOps as four specific buckets.

These buckets are as follows:

CulturePeopleProcessTechnology

I firmly believe the order of these matters. While the ambition may be to work on tooling first, following the order set out here will ensure your organizations get much more value from their DevOps transformation.

Important note

Culture is one of the most important aspects of a successful DevOps transformation, even above the use of technology.

The importance of culture in DevOps cannot be overstated; getting the right culture in your organization enables you to drive in the right direction and get more value later in the transformation. You should also not underestimate the challenge of changing an organization's culture – it requires drive and executive-level support to be successful.

Next is people, the lifeblood of any business and any product. You must ensure that you have the right people to get the right culture to achieve the goals that have been set out by your organization, and those people must have the right skills to achieve this. As important as executive-level support is to DevOps, so is having the right people to execute it.

Now, we have process. The right-minded people will be the ones who can work with and drive your processes in the right direction, applying appropriate techniques to ensure your processes are fit for purpose in a DevOps world. To work together, you need to adopt some processes for continuous collaboration, such as plan, develop, release, and monitor. Finally, you need the ability to repeat those processes on demand to deliver maximum value.

Finally, technology. By this point, the work you have undertaken in your DevOps transformation should have gained incredible value for your organization, but by introducing technology, you can add yet more value. Through automation tools, your processes can now be run on demand, more frequently, and, importantly, with a level of idempotency. This means that results with the same input parameters should not change over time. This is the value automation brings over human execution.

In this section, we have looked at the values that make DevOps successful. Now that we understand what it means to implement DevOps, we will understand the challenges that DevOps will solve in our organization.

Challenges solved by DevOps

DevOps does solve many challenges in organizations. You need to be mindful that many of these challenges have existed for a significant amount of time, have become engrained in how people operate, and that it will take some time to unpick the different levels to achieve what you want to achieve.

Prior to the adoption of DevOps, organizations were ordered in functional teams and reported to line managers, siloed away from the wider business and often each other. If all the conditions were met for deployment, then code was moved through to the operations teams to deploy the application. All these teams, along with others, worked individually, in isolation, resulting in time-consuming activities that were repeated and results that were not satisfactory.

The challenges of DevOps can generally be explained by three statements, which are as follows:

Developers are unaware of quality assurance and operations roadblocks.Quality assurance and operations teams are generally unaware of the business purpose and value of the product.As teams work individually, each team has their own set of goals, often in conflict with other teams' goals. This leads to inefficiencies.

The best example for the last point in the preceding list can be made using development and operations teams. The developer's priority is to release new features to the product quickly, while the operations team's priority is to keep the application available and performing highly. These two goals are conflicting, which leads to inefficiencies between those teams.

Addressing these challenges

These challenges are addressed in DevOps by making teams cross-functional, working in collaboration with each other and communicating about other's work and the end results. Overall, this approach increases the feedback's quality and resolves issues with existing automation.

In DevOps, most processes are continuous. With the help of feedback cycles to improve on what you already have, this gives you the ability to constantly mature and evolve your processes, thus learning from previous situations and becoming a more mature team.

Important ote

Addressing the challenges of DevOps is a time-consuming task; you should not expect instant results from a few days or weeks of effort. It will take many months to achieve the goals you have set out.

Now that we have understood the challenges associated with DevOps, it's time to look at the phases of maturity in DevOps and see how an organization will progress based on them.

Phases of DevOps maturity

Organizations should be looking to mature the more they process and adopt different DevOps best practices. This is known as maturity, and four phases are used to describe the phases of maturity in DevOps.

These phases are as follows:

WaterfallContinuous integrationContinuous deliveryContinuous deployment

Throughout the cycle of DevOps transformation, organizations should move from waterfall toward continuous deployment, visiting each stage along the way. However, it is worth noting that waterfall is not always the starting point; some organizations start later in the phases.

During the transformation process, you will find that different teams gain maturity quicker than others. There are many factors for this, including the type of work that the team does, the processes they have to follow, and, to a degree, the level of automation and tooling they already have in place.

Waterfall

The term waterfall will be common to you if you have worked on projects in the past. Waterfall is a project delivery mechanism where tasks are completed in a sequential order to achieve a specific goal. It can also be used to explain a method of software development.

Where development teams write code over a long period of time, those teams then merge their code in order to release the latest version. In this case, so many changes have been made to the code base that integrating the new version could take months. This is because the code looks so different from the previous version.

Waterfall has been in the world of project management for a long time, and even with the adoption of Agile getting more and more popular, many projects are executed using the waterfall methodology successfully.

The advantages of using waterfall as a delivery method are as follows:

Simple model to use and easy to understand.Rigidity makes it easy to manage; each phase has specific deliverables.In smaller projects, it works well as the requirements are well understood.Stages for delivery are clearly defined.Milestones are well understood.Arranging tasks with resources is simple.Processes and their results are well documented.

That being said, waterfall does have several disadvantages, as with all process models. Some of these disadvantages are as follows:

No time for revision or reflection.High amounts of risks and uncertainty.Not a good model for projects that are complex and object-oriented.Poor model for long-term projects.No working software is produced until late in the project.Measuring success within stages is difficult.Integration is done at the end in a big bang, making identifying bottlenecks hard.

Agile addresses some of these challenges and together with DevOps, you can address a large number of the challenges described here.

Continuous integration

Continuous integration (CI) is the practice of quickly integrating newly developed code with the rest of the application code to be released. This saves time when the application is ready to be released. This process is usually automated and produces a build artifact at the end of the process.

The process of CI contains a number of steps, and these are critical to achieving CI, which is meaningful and efficient. Automated testing is the first step toward CI. Four main types of tests exist that can be automated as part of CI. These tests are as follows:

Unit tests: Tests that are narrow in their scope. They usually focus on a specific part of code, such as the method of a function, and is used to test the behavior of a given set of parameters.Integration tests: Ensures that different components work together. This can involve several parts of your application, as well as other services.Acceptance tests: In many ways, this is similar to integration tests. The big difference is that acceptance tests focus on the business case.User interface tests: Tests that focus on how the application performs from a user's perspective.

Important note

One vitally important element of CI is that you integrate early and integrate often.

When you integrate early and often, you reduce the scope of changes, which, in turn, makes it easier to identify and understand conflicts when they occur. Another big advantage of this approach is that sharing knowledge is easier as the changes are more digestible than big bang sets of code changes.

Another note is that if the main branch becomes broken by a commit in code, then the number one priority is fixing it. The more changes that are made to the build while it's broken, the harder it will become to understand what has broken it.

Every new piece of work that you implement should have its own set of tests. It's important to get into this habit of writing granular tests and aiming for a level of code coverage, as this gives you a comfortable level of knowledge that you are testing the functionality of your application sufficiently.

The value of CI is realized when the team makes changes on a frequent basis. It's important to make sure that your team integrate these changes daily. Integrating often, as you may recall, is key to making sure we can easily identify what is broken.

Continuous delivery

Continuous delivery (CD) is an approach where teams release products frequently and with high quality, and with a level of predictability from source code repositories through to a production environment using automation. It builds on the work that's done in CI to take the build artifact and then deliver that build to a production environment.

CD is, in fact, a collection of best practices associated with Agile. It focuses your organizations on developing a highly streamlined and automated software release process. At the core of the process is an interactive feedback loop.

This feedback loop, sometimes referred to as continuous feedback, centers around delivering software to the end users as quickly as possible, learning from experience, and then taking that feedback and incorporating it into the next release.

CD is a separate process to CI, but they chain off each other and in mature organizations, they are used together. This means that on top of the work you have done in CI to attain levels of automated testing, you can now automatically deploy all those changes after the build stage.

With CD, you can decide on a schedule that best suits your organization, whether that's daily, weekly, or monthly – whatever your requirements may be. If you want to get the true benefits of CD, then deploy to production as soon as possible to make sure that you release small batches that are easy to solve in case of problems that may arise.

Continuous deployment

Continuous deployment is one step beyond continuous delivery. Every change that passes through all the stages of your production pipeline is released to your customers. There is no human intervention – a failed test, at this stage, will prevent new releases to production.

Continuous deployment is a great way to speed up the feedback loop and take the pressure off as there is no release day. Developers are then able to focus on building high quality software while seeing their work go live minutes after they've finished working on it. Continuous integration is part of both continuous delivery and continuous deployment. Continuous deployment is very similar to continuous delivery; the difference is that releases take place automatically:

Figure 1.1 – Showing the differences between continuous integration, delivery, and deployment

In this section, we have looked at the major phases of maturity in DevOps. Armed with this information, we can now look at how Agile plays a role in DevOps.

How does Agile play a part in DevOps?

It is common to confuse the terms Agile and DevOps. Both are used together frequently and can be used interchangeably, but they are mutually exclusive terms. Where DevOps is the practice of bringing together development and operations teams, Agile is an iterative approach that focuses on collaboration, feedback, and small rapid releases.

While both are exclusive, you will find that, by the short comparison provided previously, the goals and values of DevOps are those of Agile as well. Agile is a key part of DevOps. While Agile focuses on constant changes and making developers and development cycles more efficient, DevOps brings in the operations teams to enable continuous integration and continuous delivery.

As a project delivery framework, Agile helps address some of the disadvantages of waterfall. It would be very difficult, if not impossible, to implement DevOps using waterfall practices due to the practices of continuous integration, continuous deployment, and continuous delivery. This is one major reason why, in organizations that practice DevOps well, teams use Agile as a delivery method.

The Agile manifesto

In 2001, 17 people met in the Wasatch Mountains in Snowbird, Utah. Their aim was to discuss the future of software development. What followed was an agreement on the frustration of the current situation of software development, even if the group could not agree on how to resolve the situation.

The group agreed that organizations were too focused on planning and documenting their software development cycles, which meant organizations lost focus and sight of what was important: customer satisfaction.

Most organizations discuss corporate values such as excellence and integrity, but these values have done nothing to foster people toward a better way of working, especially software developers. This was something that needed to change. Several members of the Snowbird 17, as they came to be known, already had ideas about how to revolutionize software development and start a new era. This trip to the mountains was the group's chance to define this new era.

What came out of this trip was the Agile manifesto. At just 68 words, this short and sweet document changed software development forever. The publication of the 12 principles defined in the manifesto has arguably led to the biggest change in software development. In the two decades that have followed, these 12 principles have been embraced by individuals, teams, and organizations around the world.

Defining culture

The Agile landscape is cluttered with ideas that seem to take Agile and transform them into real-world scenarios. This isn't anything new, though; in fact, the manifesto was born out of the need to find some common ground between Scrum, Crystal Clear, Extreme Programming, and other frameworks.

One of the biggest goals of the Snowbird 17 was to see if the representatives of these frameworks could agree – they did. The agreement ended up as a set of values that define a culture.

The Agile manifesto defines the following set of values:

Individuals and interactions over processes and toolsWorking software over comprehensive softwareCustomer collaboration over contract negotiationResponding to change over following a plan

You can look at the full manifesto that came out of the meeting in the mountains on the Agile Manifesto website at http://Agilemanifesto.org/.

Another product of the summit was the 12 principles (https://agilemanifesto.org/principles.html), which adhere to these values. They expand on the preceding four sentences that make up the values.

These 12 principles are as follows:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale.Businesspeople and developers must work together daily, throughout the project.Build the project around motivated individuals. Give them the environment and support they need and trust them to get the job done.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.Working software is the primary measure of progress.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.Continuous attention to technical excellence and good design enhances agility.Simplicity – the art of maximizing the amount of work not done is essential.The best architectures, requirements, and designs emerge from self-organizing teams.At regular intervals, the team reflects on how to become more effective, then tune and adjust their behavior accordingly.

Even if you had very little exposure to Agile and DevOps before reading this book, in those 12 principles, I hope you can see the connection between what we have explored so far and the principles of the Agile manifesto.

Do Agile and DevOps work together?

Agile and DevOps can sound like very different concepts. In fact, most people I speak to in the early stages of transformation are very confused by the idea of both. This confusion is also compounded as both have their own jargon and slogans. It is common for people to become frustrated with the plethora of definitions for DevOps.

Most people think that when you say Agile, you mean Scrum, and that when you say DevOps, you really mean continuous delivery. This simplification then creates tension between Agile and DevOps, to the degree that you would be forgiven for not realizing that Agile and DevOps are friends.

It was back in 2008, at the Agile Conference, that a session about Agile Infrastructure by Patrick Debois and Andrew Clay Schafer was undertaken, and the connection to DevOps was born. Patrick later coined the term DevOps, and the Agile Conference continues with a DevOps track to this day.

There is more to this than history, though. Now, let's look at the practical connections between Agile and DevOps by looking deeper than Scrum and continuous delivery.

Agile is more than Scrum

At the point when the limitations of the business or the work itself request something else, a deft group will use the basic standards of Scrum, review their practices, and adjust them to turn out to be more viable. This is especially significant when Scrum is applied external to the setting of programming advancement.

Dealing with unplanned work

In the DevOps people group, those with Agile experience recognize that Scrum is helpful for following arranged work. Some work in activities can be arranged: delivering a major framework change, moving between server farms, or performing framework overhauls. In any case, a large part of crafting tasks is spontaneous: execution spikes, framework blackouts, and traded off security. These occasions request quick reaction. There's no longer an ideal opportunity to trust that the things will be organized in excess or for the following run arranging meeting. Consequently, numerous groups that have come to grasp DevOps thinking look past Scrum to Kanban. This encourages them track the two sorts of work and causes them to comprehend the interaction between them. Then again, they embrace a cross-breed approach, frequently called Scrumban or Kanplan (Kanban with an accumulation).

From various perspectives, the way into Scrum's wide appropriation might be that it endorses no specialized practices. Scrum's lightweight administration rehearses frequently have a major effect on a group. Where there was once contending needs from different experts, there is currently a solitary arrangement of needs in the overabundance. What's more, where there was once an excessive amount of work in advancement, there is currently an arrangement that's obliged by what time has demonstrated is truly conceivable. In the mix, these can take a group higher than ever in terms of efficiency. Be that as it may, the group may wind up obliged due to the absence of specialized practices, such as coding audits, computerized acknowledgment tests, and persistent joining.

Other Agile cycles such as Extreme Programming have solid feelings about how specialized practices uphold the group's capacity to keep an economical movement and give straightforwardness and perceivability to executives and partners. Some Scrum groups resort to placing specialized undertakings in this overabundance. While that fits well for the direction of Scrum, it rapidly hits the handy issue of Product Owner inclination toward highlights. Unless the Product Owner is very specialized, she or he might not have the right stuff to assess the cost/advantage of specialized practices. That gets much harder for a Product Owner as the specialized assignments stretch into tasks to help unwavering quality, execution, and security.

What is Scrum?

Scrum is a system that assists groups with cooperating. Scrum urges groups to learn through encounters, self-coordinate while dealing with an issue, and consider their successes and misfortunes to constantly improve.