Book Image

Designing and Implementing Microsoft DevOps Solutions AZ-400 Exam Guide - Second Edition

By : Subhajit Chatterjee, Swapneel Deshpande, Henry Been, Maik van der Gaag
Book Image

Designing and Implementing Microsoft DevOps Solutions AZ-400 Exam Guide - Second Edition

By: Subhajit Chatterjee, Swapneel Deshpande, Henry Been, Maik van der Gaag

Overview of this book

The AZ-400 Designing and Implementing Microsoft DevOps Solutions certification helps DevOps engineers and administrators get to grips with practices such as continuous integration and continuous delivery (CI/CD), containerization, and zero downtime deployments using Azure DevOps Services. This new edition is updated with advanced topics such as site reliability engineering (SRE), continuous improvement, and planning your cloud transformation journey. The book begins with the basics of CI/CD and automated deployments, and then moves ahead to show you how to apply configuration management and Infrastructure as Code (IaC) along with managing databases in DevOps scenarios. As you make progress, you’ll explore fitting security and compliance with DevOps and find out how to instrument applications and gather metrics to understand application usage and user behavior. This book will also help you implement a container build strategy and manage Azure Kubernetes Services. Lastly, you’ll discover quick tips and tricks to confidently apply effective DevOps practices and learn to create your own Azure DevOps organization. By the end of this DevOps book, you'll have gained the knowledge needed to ensure seamless application deployments and business continuity.
Table of Contents (27 chapters)
1
Part 1 – Digital Transformation through DevOps
5
Part 2 – Getting to Continuous Delivery
9
Part 3 – Expanding Your DevOps Pipeline
15
Part 4 – Closing the Loop
18
Part 5 – Advanced Topics

The five stages of the DevOps evolution

When you are trying to move to a DevOps culture in your organization, it 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 ways of working. Others that have gone before you have gone through the following five steps or stages, which may help you. Knowing about them can help you accelerate your 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 adopting. At a minimum, there are good tools for source control and often, a company standard and continuous integration and delivery are rolled out. Teams also work 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

At 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

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

Automating infrastructure delivery

At this stage, the infrastructure that is used by developers and operations becomes fully aligned. Everything is deployed from source control and the same scripts or solutions are 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 mean that environments are no longer created manually, but through self-service APIs that operations teams make available to developers.

This way, developers can 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.