Azure Pipelines is a great tool for doing Continuous Integration and Continuous Deployment and thanks to Multi Stage Pipelines we can finally have build, test, and release directly expressed in source code.
Recently they have also introduced the concept of "Environments", which belongs to the release process.
The question is: why should I use an environment to deploy my application?
Let's answer that together.
Video
If you are a visual learner or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation, which to be fair is much more complete than this post.
If you rather prefer reading, well... let's just continue :)
Environments
Environments basically represent a group of resources for a Pipeline, and allow you to map your organization physical or virtual environments like “development”, “staging”, “production”, etc, into Azure DevOps.
And while environment at its core is a grouping of resources, the resources themselves represent actual deployment targets.
At the time of writing, there are 2 types of resources you can use in Environments: Kubernetes clusters and Virtual Machines. Other resource types, like Azure WebApp, Databases, etc are coming soon.
Using an environment unlocks all kinds of capabilities, like:
- Traceability of commits and work items
- Deployment history down to the individual resource
- Deeper diagnostics
- Approvals, and checks
Additionally, when you target an Environment from your Azure Pipeline, you don't have to specify any Service Connection or credentials in the YAML files because they are automatically inherited from the Environment itself.
Approvals
Environments are also the way Multistage YAML Pipelines handle Approvals. If you are familiar with the Classic Pipelines, you know that you can set up pre- and post-deployment approvals directly from the designer.
With YAML Pipelines, the way to do that is in the Environments. Approvals and other checks are not defined in the YAML file to avoid that users modifying the pipeline YAML file could modify also checks and approvals.
Take a look at my video here to see how to use them.
Security
Let's now talk a minute about security.
There are two concepts here: User Permissions and Pipeline Permissions
With user permissions, you can control who can create, view, use, and manage the environments. There are four roles - Creator (scope: all environments), Reader, User, and Administrator.
If you create an environment within a YAML, contributors and project administrators will be granted Administrator role. This is typically used in provisioning Dev/Test environments.
If you create an environment through the UI, only the creator will be granted the Administrator role. You should use the UI to create protected environments like for example a production environment.
Pipeline permissions, instead, can be used to authorize all or selected pipelines for deployment to the environment.
Examples
Take a look at my video on YoutTube here to see how to create, manage, and secure the Environments in Azure DevOps.
It contains also examples on how to use them in real Pipelines, especially for Approvals and Checks
Like, share and follow me 🚀 for more content:
📽 YouTube
☕ Buy me a coffee
💖 Patreon
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast
Top comments (6)
Hey Davide, Thanks for this post. Nice work! Is it possible to prevent the "automatic" creation of environments and only allow creation through the UI?
Hi. No, afaik there is no way to disable the automatic creation of environments from YAML. It would be nice doing so for some cases, because you might not want everyone to be able to create environments or, as happened to me many times :D, you misspell an environment name and so a new one is created...
Thanks! How do environments relate to the "Release" section? I'm a bit confused here!
Hey, sorry I’m not sure what you mean by “Release section“...
If you talk about the Release menu item under pipelines, that is to access the Classic Release Pipelines. Environments work only for YAML Pipelines.
Hey Davide! Thanks for responding so quickly!
I meant the "Releases" item in the left navigation menu. I had no idea it was called "Classic Release Pipelines". Why Classic? Is it being deprecated in favor of just multi-stage pipelines? I really like the UI of release pipelines, not only the visual stages but also the possibility to retry a deployment etc.
From what I understand so far:
Is that so? Are there plans to make everything interoperable?
Thanks!!
Hey. It is called "Classic" because it was the only option available until the YAML Pipelines have been released more recently. Both are fully supported and will still be, there is no plan to deprecate any of them. The Classic (aka UI-made) pipelines are easier to start with and provide a graphical way to visualize the flow, while the YAML ones (aka code-based) provide a way to store your CICD definitions in code (with all the advantages deriving from that) and are more flexible, if you will.
Your 3 points are correct, to summarize and extend:
This is to say you can concatenate different ways.
While Classic and YAML are mostly at feature parity, there is no plan to make Environments work in Classic. And this is partially because in Classic Release you can define your stages (aka steps) visually and those somehow represent your environments. But it is true that you lose some logs and info in that way, which are otherwise available in Environments.