Demystifying Azure DevOps Services

A Guide to Architect, Deploy, and Administer DevOps Using Microsoft Azure DevOps Services

Ashish Raj

• Editorial: BPB Publications
• Año: 2021
• ISBN:
  9789389898682
• Categoría: Informatique
• Categoría: Développement de logiciels

Learn about Azure DevOps services to successfully apply DevOps strategies

Key Features

• Share knowledge on DevOps implementation and use of Azure DevOps services.
• Learn about Azure artifacts, dependency management, and CI/CD pipeline management.
• Manage third-party integration, Agile planning, and application lifecycle management.

Description
This book offers readers the best DevOps practices and explains how to implement various services of Azure DevOps to ensure efficiency, effectiveness, and better management of the entire software development lifecycle.This book explains each component of Azure DevOps services, their pricing models, and a quick tutorial on how to proceed with its usage. Backed with numerous examples, this book helps you implement Agile planning using Azure Boards, maintain code versioning using Azure Repos, and manage CI/CD using Azure Pipelines. You will learn how to administer the DevOps process such as managing packages using the most popular Azure Artifacts and how to run Test Plans using Azure Test Plans. You will also learn how to integrate with third-party systems. Finally, you will learn about marketplaces of extensions and how to develop your own extensions.

What you will learn

• Learn DevOps culture, practices, and habits.
• Learn to manage version control of the source code within Azure DevOps Services.
• Learn how to administer Azure DevOps services for an enterprise application lifecycle management system.
• Learn Azure DevOps services and features.

Who this book is for
This book is for anyone who wishes to use or who are using Azure DevOps services, including Infrastructure engineers, Software engineers, Architects, Testers, Managers, or Product Owners.

Table of Contents
1. Introduction to Azure DevOps
2. Azure DevOps Organization
3. Azure DevOps Project
4. Azure Board
5. Azure Repos
6. Azure Pipelines
7. Azure Artifacts
8. Azure Test Plans
9. Extension Marketplace

About the Authors
Ashish Raj is a technologist and storyteller who helps engineering teams improve their velocity. He believes the biggest challenges facing engineers aren't technical, but not knowing how to tie people, process, and technology. He is a Microsoft certified trainer, founder of the AzureDevOpsPro community, and cofounder of the AzureTalk community. Blog links: https://www.azuredevopspro.com
LinkedIn Profile: https://www.linkedin.com/in/ashishrajsrivastava/

CHAPTER 1

Introduction to Azure DevOps

Introduction

DevOps as a culture, helps you bridge the gaps between different teams involved in the software development lifecycle. To help teams adopt this culture, having a good tooling strategy plays an important role. Azure DevOps Services provides different services or integration that supplements your tooling needs in the DevOps adoption journey.

Structure

In this chapter, we will cover the following topics:

• DevOps, its practices and habits
• Azure DevOps Services and how it helps you in DevOps adoption
• Who should learn DevOps and how to learn
• Azure DevOps Services components

Objectives

This chapter introduces DevOps as a culture and helps you understand its seven practices and habits. After studying this chapter, you should be able to embrace DevOps as a culture and the tools you need in the DevOps journey. You will be able to understand the various terms like continuous integration, continuous delivery, continuous deployment, infrastructure as code, etc. You will know how DevOps relates to everyone who get involved in a Software development life cycle, and how one can kick start the learning journey into DevOps. We will explore a few useful learning paths, certifications and other study materials. You will also explore the various services offered by Azure DevOps Services, and how they map with the common DevOps common practices.

DevOps, what is that?

DevOps has been a trending term in recent days for many good reasons, and different people have different perspective of DevOps about how to use it or why? For some people, its some set of tools that gets DevOps into the team, some people think it’s a set of technology that gives you DevOps, and for some people, it’s a dedicated team with a set of skills. While many are true in their respective implementation, to refer to the real meaning of DevOps, we may quote the definition of DevOps by Donavan Brown, DevOps program manager at Microsoft.

"DevOps is the union of people, process, and products to enable continuous delivery of value to our end users."

Figure 1.1: DevOps

The preceding figure 1.1 demonstrates DevOps in practice, when such collaborations happen between people working in different roles to achieve the overall goal supported by different tooling and processes.

Let’s expand the statement with some more words, which can help us understand this statement in more details.

The first keyword that I would like to emphasize is People – journey to DevOps culture starts with your people. The people, here, includes everyone that have some role in your application life cycle, whether its Developers, Infrastructure engineers, Managers, Product owners or even business. They build your product, service, or value that you deliver as a team, so a mindset, which emphasizes on people and the way they work, learn, or collaborate is a must have.

Process is the next word that has a significant role in your DevOps journey. Based on your people, you align the processes, so that they can deliver the values individually, as well as collaborate better to achieve the collective organizational goal. Its important to have your people considerations when you are working out on a process on which they will be working.

Once you understand your people and have a proposed plan for the process, you may need tools or Products that can help you align them together to deliver value. When this happens, you deliver the value again and again with more agility and feedback loops. That’s when you get into what we call DevOps culture.

DevOps is also said to be originated as a result of demands from agile development teams from IT Infrastructure and operations in terms of frequent release deployment and reliable production site with Live Site habit in practice. Over a period of years, agile has become a popular choice of process among software development teams. The main reason of its popularity is that it allows software development teams to achieve frequent release cadence. But this did not mean that the frequent release could be deployed as fast as they were being released by development teams.

The traditional IT operations teams were struggling with the demands of faster release cadence by agile software teams. IT operations was still stuck in old bureaucratic processes and mostly manual deployment with least automation in their work. IT operations was in the mindset of "don’t change if it’s running", however agile mindset focuses on "change frequently, fail fast, and redeploy".

These two mindsets were contradicting to each other, until IT operations team was introduced to the concepts of DevOps. DevOps brought them to a state, where they can complement agile processes and move the value from code to the production, as soon as it’s available from the release cadence of Agile software development teams. If at all any issue comes, operations should be equipped with mindsets and tooling that can help them to find the root cause of the issue, fix it as soon as possible, and even feed backlog with feature that may prevent issues in the future.

DevOps expects IT operations to run with a mindset of "you build it and you run it", which is being practiced in some organizations as Site Reliability Engineering (SRE). Also the collaboration gaps between development and IT operations resulted into unclear requirements of infrastructure for the application deployments or more lead time to fix issues in production. This is due to less knowledge about how application works or what it expects from running environments in terms of resources, configurations, networks, or security. DevOps advocates cross team collaboration to foster cross skilling as well as embrace them to work together to achieve a common organization goal.

Collaboration plays an important role in the DevOps journey and leads to a successful DevOps adoption in any organization. In a DevOps organization, people across different teams having different skill set, collaborate effectively to ensure a high-quality value deployed frequently. The following figure 1.2 demonstrates the flow of messages and information between teams , processes, and tools with effective collaboration:

Figure 1.2: Collaboration

Here are the seven key DevOps practices:

Figure 1.3: DevOps seven key practices

Let’s explore the details of these seven key practices being shown in the preceding figure 1.3.

1. Configuration Management: Configuration Management refers to maintaining systematic changes in the server environments and running your applications in a way that it maintains integrity over time. This helps in easy and quick deployment of application or update to existing application, easy recovery from any disaster or unwanted changes, and prevent snowflakes servers. Over a period of time, configuration of systems becomes unknown, either due to unknown manual changes or as part of patch installations. Its important to know the working configuration of the servers, as well as maintain it using practices, such as Configuration as Code.
   Configuration as Code focuses on maintaining your infrastructure configuration in code, just as developers maintain application’s code. It gives you traceability of configuration changes, as well as allows you to spin up the resources with expected configuration on demand. There are tools like PowerShell DSC, Chef, Puppet or Ansible, and so on, which are used by many operations team to manage their configuration as code. Essentially these tools can accept configuration in some specific script or programming language format, such as JSON or YAML, and so on. These tools interpret the provided input script using some kind of configuration engine implemented within, and then communicate to the server to make the specified changes in the input script. Most of these configuration management tools use the concept like Desired State Configuration to frequently check the managed servers, and if the server is drifted from its desired state, then the desired configuration is applied again by the Configuration engine. As you can see in the following figure 1.4, configuration is being applied by configuration manager engine on target servers. Configuration Manager engine also keeps checking the state of managed target servers, and make sure the settings are applied again if a drift is reported.

   

   Figure 1.4: Configuration as Code
2. Release Management: Scheduling build promotion to different environment, like QA, UAT, Staging or Production, must be managed properly, so that unsuccessful outcomes can be caught early before it hits the real user in production. Release Management ensures this – using proper strategy and tooling that makes sure proper notifications and automated testing environments or artifacts are ready to be consumed as soon as the latest changes in code passes the build. Release management makes sure the proper validation in terms of integration tests, load tests, or manual QA validation passes the build to promote to the next environment with proper tracing, including build versions, test results and approvals. The following figure 1.5 shows a typical release management process flow, where CI build packages are picked as soon as the latest version is available, and get deployed to different environment, either automatically or after a manual approval by Release Managers:

   

   Figure 1.5: Release Management
3. Continuous Integration (CI): CI ensures that as soon as new code is pushed by developers to the version control system, the build system will be triggered and will validate the build. Validation is done by running the automated test suite or any task that needs to be performed to create the artifacts which can be deployed further. CI fulfils two objectives, the first and the most important is that it provides continuous and prompt feedback to developer about the changes made. If build fails, developer will get notification, and it is expected to correct the code, so that it can pass the build process. The second most important aspect of having CI system is that it makes your artifacts available to be consumed by Release Management as soon as it is available after passing the build. The following figure 1.6 shows whenever the new code is pushed to git version control system, it goes through a series of steps to build, run tests, and publishe a new artifact, if all pass as expected. The new artifact generated by CI systems proceed to Release management as shown in the preceding figure 1.5.

   

   Figure 1.6: Continuous Integration
4. Continuous Deployment: Continuous Deployment is a next step after CI is in place. CI ensures a continuous delivery, that is, your artifacts will be made available continuously (delivering value as new features in the latest artifacts), but it may not be deployed continuously. What we mean here as having artifacts continuously is one thing, but you may not want to automatically run the deploy steps for the latest build and may want to validate it first. It can be a manual push or another system that needs to be triggered to allow deployment. In such scenarios, we call it continuous delivery (not deployment). If your tool chain and deployment task validations are mature enough over period and calls the automatic triggers of deployment to different environments, such QA, Stage or Prod, then that is a continuous deployment pipeline as shown in the following figure 1.7.
   In a continuous deployment pipeline, builds are deployed only if the defined tests in the pipeline are passed. There is no manual approval or push required anywhere in between. Ideally, pipelines start with a continuous delivery and deployment with a set of manual tests or approvals. Over a period and based on learnings from the environments, you keep putting more validation logic within pipeline, using some kind of automation, either using scripts or tooling and reduce dependency on manual tests, or approvals to reach the ultimate goal of continuous deployment.

   

   Figure 1.7: Continuous Deployment
5. Infrastructure as Code: Most of the software have been built using one or many coding platforms like .NET, Java, Python, and so on. However, infrastructures were built mostly using manual processes with some imperative scripts. It generally had the number of steps listed in some documents and were mostly executed using GUI and manual in nature. The problem with this approach is that it is time consuming, prone to human errors, and difficult to automate. Another problem that arises due to such manual processes is that the IT Infrastructure team is not able to cope up wi...