Implementing Azure DevOps Solutions

Learn about Azure DevOps Services to successfully apply DevOps strategies

Henry Been, Maik van der Gaag

• Publisher: Packt Publishing
• Year: 2020
• ISBN:
  9781789616354
• Edition: 1
• Topic: Ciencia de la computación
• Subtopic: Arquitectura de sistemas

A comprehensive guide to becoming a skilled Azure DevOps engineer

Key Features

• Explore a step-by-step approach to designing and creating a successful DevOps environment
• Understand how to implement continuous integration and continuous deployment pipelines on Azure
• Integrate and implement security, compliance, containers, and databases in your DevOps strategies

Book Description

Implementing Azure DevOps Solutions helps DevOps engineers and administrators to leverage Azure DevOps Services to master practices such as continuous integration and continuous delivery (CI/CD), containerization, and zero downtime deployments.

This book starts with the basics of continuous integration, continuous delivery, and automated deployments. You will then learn how to apply configuration management and Infrastructure as Code (IaC) along with managing databases in DevOps scenarios. Next, you will delve into fitting security and compliance with DevOps. As you advance, you will explore how to instrument applications, and gather metrics to understand application usage and user behavior. The latter part of this book will help you implement a container build strategy and manage Azure Kubernetes Services. Lastly, you will understand how to create your own Azure DevOps organization, along with covering quick tips and tricks to confidently apply effective DevOps practices.

By the end of this book, you'll have gained the knowledge you need to ensure seamless application deployments and business continuity.

What you will learn

• Get acquainted with Azure DevOps Services and DevOps practices
• Implement CI/CD processes
• Build and deploy a CI/CD pipeline with automated testing on Azure
• Integrate security and compliance in pipelines
• Understand and implement Azure Container Services
• Become well versed in closing the loop from production back to development

Who this book is for

This DevOps book is for software developers and operations specialists interested in implementing DevOps practices for the Azure cloud. Application developers and IT professionals with some experience in software development and development practices will also find this book useful. Some familiarity with Azure DevOps basics is an added advantage.

Section 1: Getting to Continuous Delivery

In this section, you will learn about the fundamental principles of DevOps, along with the practices that most organizations start with, namely, continuous integration and continuous deployment. This section creates the necessary foundations for our work, after which most of the other chapters can be read in any order.

This section comprises the following chapters:

• Chapter 1, Introduction to DevOps
• Chapter 2, Everything Starts with Source Control
• Chapter 3, Moving to Continuous Integration
• Chapter 4, Continuous Deployment

Introduction to DevOps

DevOps is not a product or tool that you can buy or install. DevOps is about culture and the way you write, release, and operate your software. DevOps is about shortening the time between a new idea and your first end user experiencing the value it delivers. In this book, you will learn about the tools and techniques to apply that philosophy to your way of working.

To enable this, you might have to change the way you work and adopt new tools or change the way you use them. In this first chapter, you will learn more about what DevOps really is and how to recognize a successful DevOps team.

The following topics will be covered in this chapter:

• What DevOps is and why you cannot simply buy or install it
• How DevOps complements Agile
• What the benefits of DevOps are and how to measure them
• Creating your ideal DevOps and organizational structure
• Exploring DevOps practices and habits of successful DevOps teams
• The five stages of DevOps evolution

Technical requirements

There are no technical requirements for this chapter.

What is DevOps?

If you were to list all of the different definitions and descriptions of DevOps, there would be many. However, as different as these might be, they will most likely share several concepts. These are collaboration, continuous delivery of business value, and breaking down silos.

With all of the technical discussion in the rest in this book, it is important not to overlook the value proposition for adopting DevOps, namely, that it will help you to improve the way that you continuously deliver value to your end users. To do this, you have to decrease the time between starting work on a new feature and the first user using it in production. This means that you not only have to write the software but also deliver and operate it.

Over the last decade, the way we write software has fundamentally changed. More and more companies are now adopting an Agile way of working to increase the efficiency of their software development. More and more teams are now working in short iterations or sprints to create new increments of a product in quick succession. However, creating potentially shippable increments faster and faster does not create any value in itself. Only when each new version of your software is also released to production and used by your end users does it start delivering value.

In traditional organizations, developers and operators are often located in different departments and taking software into production includes a hand-off, often with a formal ceremony around it. In such an organization, it can be hard to accelerate that delivery to production along with the speed at which development can create new versions.

Next to that, development and operations departments often have conflicting goals. While a development department is rewarded for creating many changes as fast as possible, operation departments are rewarded for limiting downtime and preventing issues. The latter is often best achieved by having as few changes as possible. The conflict here is clear—both departments have optimizations for one subgoal, as shown in the following diagram:

This defeats the purpose of these subgoals, which comes from the shared, overarching goal of quickly taking in new versions while maintaining stability. Precisely this conflict between developmental and operational goals is one of the things that should disappear in a DevOps culture. In such a culture, developers and operations teams should work together on delivering new versions to production in a fast and reliable manner and share responsibility for both subgoals.

While it is good to know that DevOps is a cultural movement, tools and automation are an important part of that culture. In this book, the focus will be on these tools and how to use them to implement many of the practices that come with a DevOps culture. In other words, this book will be mostly on the products and processes associated with DevOps. If you want to learn more about the cultural side of things, about the people, there are many other books to read.

The rest of this section will explore the relation between DevOps to see how they complement each other. The focus will be on Agile techniques and prices for work management. We will also discuss the goals and benefits of a DevOps culture.

The relation between DevOps and Agile

If you take a look at Agile, you might notice that part of it is the focus on business value and shortening the time between the delivery of a new business value. From that perspective, adopting DevOps is a logical next step after Agile. Agile advocates that the software development teams' responsibilities should extend forward by engaging with users and other stakeholders to more quickly deliver valuable potentially shippable products. DevOps is all about not just creating something that might be shipped, but really shipping it as well. With Agile and DevOps combined, you can create an end-to-end, continuous flow of value to your users.

One of the things you need to be able to do this is a common approach to managing the work to be done for everyone involved. In the next section, you will find some pointers on how to incorporate operational concerns in the way you manage your work.

Agile work management

When you are starting to increase the collaboration between development and operations, you will quickly notice that they have to cope with different types of work. In development, a large part of the work is planned: user stories and bugs that are picked up from a backlog. On the other hand, for operations, a large part of their work is unplanned. They respond to warnings and alerts from systems and requests or tickets from users or developers.

Integrating these two, especially if developers and operators are located on the same team, can be challenging. To see how you can deal with this, let's explore the following approach:

1. First, switch to a flow-based way of working for developers.
2. Next, allow for operations to also list their work in the same work management system as developers using synchronizations. You can also choose to implement fastlaning, an approach to expedite urgent work.
3. Finally, you might choose to decommission existing ticketing tools for operations if possible.

Fastlaning is an approach to organizing work that allows for both planned and unplanned work by visualizing two separate lanes of work. To do this, the Scrum board is extended with a Kanban-like board on the top. This is the fast lane. On the Kanban board, urgent but unplanned work is added. Any work added to this lane is picked up by the team with the highest priority. Only when there is no work remaining in the fast lane is work from the Scrum board with planned work picked up. Whenever new work is added to the fast lane, this takes priority again. Often, there is the agreement though that work in progress is finished before switching to work in the fast lane.

Switching to a flow-based methodology

The first thing to consider is transitioning the way developers work from batch-wise to flow-based. An example of a batch-wise way of working is Scrum. If you are using the Scrum framework, you are used to picking up a batch of work every two to four weeks and focus on completing all of that work within that time window. Only when that batch is done do you deliver a potentially shippable product.

When changing to a flow-based approach, you try to focus not on a batch, but on just one thing only. You work on that one work item and drive it completely until it's done before you start on the next. This way, there is no longer a sprint backlog, only a product backlog. The advantage of this approach is that you no longer decide which work to perform upfront, but whenever you are free to start on new work, you can pick up the next item from the backlog. In an environment where priorities quickly shift, this allows you to react to change more quickly.

These changes to the way developers organize their work make it easier to include operations in work management, but there is also another benefit. When developers are focusing on getting a single work item done instead of a whole sprint at once, you can also increase the number of times you can deliver a small portion of value to your users.

Synchronizing work items to one system

After the development team changes the way it organizes its work, it should now be easier for developers to also list their planned work on the shared backlog and pull work from that backlog when they have time to work on it. They now also have a place where they ca...