Azure Pipelines: Releases versus Environment for release management and deployment

Question

I'm looking at these two documents:

YAML Pipeline Environments Create and target an environment

Releases: Releases in Azure Pipelines

My team is using both for the same purpose - to release and deploy. What I'd like to know is whether we should be using one over the other as it appears as there is a lot of overlap in functionality?

Is there documentation comparing the two approaches and feature sets? I get a vague impression that Azure Releases is on the way out as it falls under the Deploy Apps (classic) doc node.

Answer 1

Azure DevOps Releases are now formally recognized as Classic Releases. This process is a GUI approached portal. This process is usually advised against if just starting out in ADO. To support this notion Microsoft recently enabled the feature to turn off classic releases. Unfortunately the feature gap between Classic Releases and Pipelines w/ ADO Environments still exists. Approve and Deploy later and ADO Work Item integration are two I constantly hear being brought up. The ADO Product team is zeroing in on this:

Customers prefer YAML pipelines over classic for builds (CI). However, for releases (CD), many customers have continued to use classic release management pipelines over YAML. The primary reason for this is the lack of parity in various CD features between the two solutions. Over the next year, we will invest in bridging these gaps. As a first step, we will focus on checks. Checks are the primary mechanism in YAML pipelines to gate promotion of a build from one stage to another.

This may ask why one would prefer ADO w/Environments over Classic Releases. ADO Pipelines that leverage Environments are Pipelines used for CI/CD that are attached to the codebase. Thus any changes to them are stored in Git and under version control. As opposed to Classic Releases where this ability was a bit more "lax" as well as the ability to update individual release instances. With YAML Pipelines this is not possible and thus can be viewed as more secure and the deployment process is repeatable.

YAML Pipelines tend to be more extendable as YAML Templates are reusable pieces of the pipeline that can be scoped at stage/job/task/variables. Classic Releases had this ability with Task Groups; however, versioning on these was both problematic for the lack of Source Control Integration as well as all consumers of the task group would need to update their version to get the latest. As opposed to YAML who would inherently receive the update if that was the desired behavior.

One must be using YAML Pipelines to leverage ADO Environments. Environments a sub type of job (deployment). Thus one would want to leverage a deployment job with an ADO Environment. The ADO Environment would act as the gate for any approvals, API calls, etc..

Also environments provide a history on all jobs that have been deployed to the environment. One matter of opinion is the deployment reporting out of ADO can be improved upon as it is a step back compared to Classic Releases. If just getting started on YAML and to learn more here is a good resource specific to ADO Environments.