Azure DevOps - Release Pipeline using Deployment Groups or Deployment Job to an Environment?

Question

I'm new-ish to Azure DevOps, so I've missed how it got to where it is. By that I mean that I've seen two different approaches for deployment to environments and I'm not sure which superseded which:

• Using a Release Pipeline and Defined Deployment Groups to deploy across stages (environments) See here
• Using a Deployment Job in a Pipeline, then using a release pipeline to orchestrate pushing it to different environments - See here

It's interesting that the first link MS docs refer to as being classic, however the latter is not.

I'm currently using Deployment Groups to define the App Servers I deploy to for each environment - then each stage in my Release pipeline targets a different deployment group (environment). This seems the most fluent and natural of the solutions. However, it niggles me that the Environments I setup in the Environments section still maintain that they have never been deployed to - but the deployment groups have recorded the deployments as I expect. Also, the environments allow me to set useful stuff like "business hours" to wake the environment machines.

I looked and tried out some of the approach in the second link I posted - however, this just didn't seem intuative to me - and I can't find much in the DevOps docs to support this approach. I can see the benefits in that you can store your deployment pipeline as code in your repo, and that you have finer controller over the whole process - but I couldn't get variables from the library to be used in any of the replace variables steps or really understand where the release pipelines fit in.

So, I guess I after an inkling of what "best practice" is in this fairly straight forward scenario. I wondering if it's a blend of the two, but to be honest - I'm a bit lost.

Answer 1

Release pipelines and deployment groups have been around for longer than Azure DevOps has been named Azure DevOps. The YAML releases are rather recent. It isn't ever spelled out explicitly, but in my mind it comes down to how you plan on delivering your product.

If you are doing Continuous delivery (choosing when to release, maybe daily, weekly, or quarterly) then I think you must use release pipelines. You might choose this also if you have multiple environments that maybe aren't in the path to production that would want to deploy.

If you are doing Continuous deployment (every push that passes tests goes to production without any real human intervention), then I imagine you'd choose to use the YAML stages. This is kind of spelled out in your second link as the approach for deploying with "release flow", which is Microsoft's approach for delivering changes for Azure DevOps.