Book Image

Implementing Azure DevOps Solutions

By : Henry Been, Maik van der Gaag
Book Image

Implementing Azure DevOps Solutions

By: Henry Been, Maik van der Gaag

Overview of this book

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.
Table of Contents (21 chapters)
1
Section 1: Getting to Continuous Delivery
6
Section 2: Expanding your DevOps Pipeline
12
Section 3: Closing the Loop
15
Section 4: Advanced Topics

Five stages of the DevOps evolution

When you are trying to move to a DevOps culture in your organization, this is going to take time. There are motions you have to go through while everyone in your organization embraces the changes they have to make to their individual way of working. Others that have gone before you have gone through the following five steps or stages that might help you. Knowing about them can help you to accelerate your own journey. These steps were first published in the 2018 State of DevOps Report and are discussed in the following sections.

Normalizing the technology stack

A common first step on the road to a DevOps culture is the adoption of Agile. At a minimum, there are good tools for source control, and often a company standard and continuous integration and delivery are being rolled out. Teams are also working together to normalize the stack they develop software for. For example, one or two cloud vendors are chosen and other deployment platforms are phased out. The same goes for tools for other purposes—they are standardized where possible. Homebrewed solutions are replaced with industry standards.

Standardizing and reducing variability

In this stage, teams work on further reducing the variation between and within applications and the development and operations teams that work on them, working together on aligning operating systems, libraries, and tools. Also, in this stage, deployment processes are changed to reduce the amount of variation between them and configuration and infrastructure are often moved to source control.

Expanding DevOps practices

Remaining issues between development and operations are cleaned up, ensuring that outputs of the development team are precisely what the operations team expects. Also, collaboration starts to grow between the two and they are able to work together without external dependencies on creating and delivering changes.

Automating infrastructure delivery

In this stage, the infrastructure that is used by developers and operations becomes fully aligned. Everything is deployed from source control and the same scripts are being used by both teams.

Providing self-service capabilities

Before DevOps, virtual machines or hosting environments were often requested from operations, by developers manually or through ticketing systems. Provisioning was done manually by operators, which could take days or sometimes even weeks.

Self-service capabilities means that environments are no longer created manually, but through self-service API's that operations teams make available to developers.

This way, developers are fully able to create and destroy environments on their own. They can create and test changes on their own and send them off or schedule them for automated deployment.