Azure DevOps Environments
By: Ivan Porta
Tags: DevOps, Tutorial, Continuous Integration, Microsoft, Azure

In today’s article, I’m going to introduce Azure DevOps environments and the benefits that their combination with Azure Pipelines will give to your deployment.

What are Azure DevOps environments?

Azure pipelines are an excellent tool for making continuous integration (CI) and continuous deployment (CD). Thanks to multistage pipelines, it’s possible to have build, test, and release together.

An environment represents a group of resources that can be targeted by deployments from a pipeline, allowing you to map physical or virtual environments such as development, production, and Q&A into agile development.

Currently, there are only two types of resources available:

· Kubernetes clusters

· Virtual machines

Other resources, like databases and Azure web apps, are still in development and will be available soon.

Why use environments?

Using environments has many advantages, for example:

· Traceability: View the jobs of a pipeline that target an environment, as well as the commits and work items that were newly deployed to the environment.

· Deployment history: The pipeline name and run details are recorded for deployments to an environment and its resources.

· Diagnose resource health: Validate whether the application is functioning at its desired state.

· Permissions: Secure environments by specifying which users and pipelines are allowed to target an environment.

Also, when you target an environment from your pipelines you don’t have to specify the service connection for your resources, because pipelines automatically use the service connection defined in that environment.

How to create and manage environments

Sign in to the Azure DevOps portal, and navigate to the Pipelines page. Once there, choose Environments and click on Create Environment.

In the window that will appear, after specifying a name and a description (optional), select the type of resources that you want to add to your environment and click on create.

If you go back to the Environments page, You’ll see the environment that you’ve just created with a “Never Deployed” status.

How to use an environment

If you already have a pipeline, skip the following instructions.

How to create a pipeline

As this article is focused on Azure environments, I’m not going to talk in-depth about Azure Pipelines. On the Pipelines page, choose Pipelines and click on Create Pipeline.

Walkthrough the different steps of the wizard by adding the location of your source code, the repository, and the configuration of your pipeline. At the end of the wizard, the portal will present the pipeline’s YAML.



# Build and test ASP.NET Core projects targeting .NET Core.

# Add steps that run tests, create a NuGet package, deploy, and more:

# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core # ASP.NET Core# Build and test ASP.NET Core projects targeting .NET Core.# Add steps that run tests, create a NuGet package, deploy, and more: trigger:

- master pool:

vmImage: 'ubuntu-latest' variables:

buildConfiguration: 'Release' steps:

- script: dotnet build --configuration $(buildConfiguration)

displayName: 'dotnet build $(buildConfiguration)'

The default template has just one implicit stage and one implicit job. To use your environment, you have to create a new deployment job that will target your environment. To do so, change the YAML as follows:



# Build and test ASP.NET Core projects targeting .NET Core.

# Add steps that run tests, create a NuGet package, deploy, and more:

# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core # ASP.NET Core# Build and test ASP.NET Core projects targeting .NET Core.# Add steps that run tests, create a NuGet package, deploy, and more: trigger:

- master pool:

vmImage: 'ubuntu-latest' variables:

buildConfiguration: 'Release' stages:

- stage: CI

displayName: CI stage

jobs:

- job: build

displayName: Build

steps:

- script: echo This is a BUILD job

displayName: 'Build project' - stage: CD

displayName: CD stage

jobs:

- deployment: deploy

displayName: Deploy

environment: Development

strategy:

runOnce:

deploy:

steps:

- script: echo This is a DEPLOYMENT job

displayName: 'Deploy project'

As you can see, there are two different stages:

· the CI stage, whose only job is to focus on building the project,

· the CD stage, whose only job is to deploy the project to the Development environment.

To complete the procedure, click the Save and Run button.

While the pipeline is running, it’s also possible to see what’s going on in real-time by clicking on the stages.

If you go back to Environments, you will see that the status of your environment has changed to “Not Deployed” for the build that has currently deployed in it.

To conclude, I want to take a moment to highlight one benefit of using environments in deployments: traceability and deployment history. If you click on your deployment, you can see the status of your deployment jobs. In this case, I have only one job targeting this environment. Still, if there had been other pipelines targeting this environment, I would have seen the list of pipelines, a list of changes, and everything that has been deployed to this environment.

If you open a single deployment, you can also look at the jobs that make up that deployment and the changes included in that deployment, all the way down to the individual work items.

References

Azure Pipelines official documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines

Subscribe to FAUN topics and get your weekly curated email of the must-read tech stories, news, and tutorials 🗞️

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬