Azure DevOps Environments

What are Azure DevOps Environments?

Azure pipelines are excellent for making continuous integration (CI) and continuous deployment (CD) in your organization. Because of multistage pipelines, you can build, test, and release at the same time. An Azure 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

Apart from these resources, databases and Azure web apps are still in development and soon you will be able to use them.

What Are the Benefits of Using Azure DevOps Environments?

Azure environments have many benefits to offer that are:

  • Traceability: You can trace the jobs of a pipeline that target an environment. At the same time, it lets you access commits and work items that were newly deployed to the environment.
  • Deployment History:  You can easily see the pipeline history, as the pipeline name and run details are recorded for deployments to an environment with its resources.
  • Diagnose Resource Health: It makes the monitoring much easier, as you can check the status of the application and validate whether the application is functioning at its desired state or not.
  • Permissions: No doubt that Azure DevOps Environments offer incredible security features. For example, it secures environments by specifying which users and pipelines are allowed to target an environment.

Besides this, anytime 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.

Difference Between Environments and Deployments Groups:

People get confused between environment and deployment groups, hence you need to understand the basic difference between the two.

  • Deployment Groups:  A deployment group is a logical set of deployment target machines that have agents installed on each target machine. Deployment groups represent the physical environments; for example, "Dev", "Test", "UAT", and "Production". In fact, a deployment group is just another grouping of agents, much like an agent pool.
  • Environment:  Environment represents a collection of resources, such as namespaces within Kubernetes clusters, Azure Web Apps, virtual machines, databases, which can be targeted by deployments from a pipeline.

In simple words, they both have the same theory in actual deployment. Since Deployment group jobs are not yet supported in YAML, in this case, the Environments come up. While the environment at its core is a grouping of resources, and these resources themselves represent actual deployment targets.

How to Create and Manage an Environment in Azure?

To create an environment, you need to sign in to the Azure DevOps portal. Once you open the portal, navigate to the Pipelines page, choose Environments and click on Create Environment.

Here, in the window, 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.

Although your environment is created, yet it shows the status as “Never Deployed” if you go back to the Environments page. Further, in this post, we will show how this status changes once you start using the environment.

How to Use an Environment?

To use the environment, you have to create a pipeline. That’s why we’ve mentioned steps to create a pipeline. But if you already have a pipeline then you can skip the following instructions.

Steps to create a pipeline:

  • On the Pipelines page, choose Pipelines and click on Create Pipeline.
  • Walkthrough the different steps and by adding the location of your source code, the repository, and the configuration of your pipeline. In the end, the portal will present the pipeline’s YAML.
  • 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:
    • You will see two different stages:
      • The CI stage, which focuses on building the project,
      • The CD stage, which deploys the project to the Development environment.

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

While the pipeline is running, you can also see what’s going on in real-time by clicking on the stages. But if you go back to Environments, you will see that the status of your environment has changed to “Not Deployed” for the build that was currently deployed in it.

Approvals in Environments

Azure lets you control a stage using approval checks. By using approval, you can control deployments to production environments. These checks are a mechanism for the resource owner to control when a stage in a pipeline consumes a resource. The owner of a resource, like an environment, can define approvals. However, the check must be satisfied before a stage starts to consume resources.

Currently, manual approval checks are supported on environments and only the creator, administrator, and user roles can manage approvals and checks. The reader cannot manage or check approval.

Security in Environments

In Azure Environments, the security feature is created to grant access to the environment. It works in two ways:

  • User Permissions:  You have control over who can create, view, use, and manage the environments with user permissions. These user permissions are defined by four roles - Creator (scope: all environments), Reader, User, and Administrator. However, you can also override the roles for each environment. You just have to go to the specific environment's user permissions panel to set the permissions.
  • Pipeline Permissions:  Pipeline permissions can be used to authorize all or selected pipelines for deployment to the environment.


The biggest advantage of using Environments in deployments is that it allows you to track the deployment history. Once you click on our deployment, it shows the status of your deployment jobs. For example, sometimes, you would see that two microservices, each with its pipeline, are deployed to the same environment. In this case, the deployment history helps you unfold the mystery by showing the list of all the pipelines impacting the same environment.