YAML based Pipelines and Release Pipelines In Azure DevOps

DevOps Azure DevOps
#1

I have a question regarding the use of YAML based Pipelines and Release Pipelines In Azure DevOps. The organization I work for develops websites/portals in .NET and Vue.JS. Every website has three different environments hosted on different on-premises Windows servers. We have TST, ACC and PROD

Currently we are in the middle of a migration from Gitlab and Jenkins to Azure DevOps. Now we are trying to replicate/port the pipelines we created in the graphical user interface in Jenkins to DevOps.
Now in Azure DevOps you can either create Release based pipelines or YAML based ones, Should you also use both of them in the same time or only use 1 type?

I can see that using the YAML ones has a few advantages over the Release Pipelines since the yaml files can be part of your versioncontrol and you have the ability to import pipelines from a dedicated pipeline repostiory so you have a single central point to manage them.

• Is everything that is possbile in the Release Pipelines also possible in YAML based ones?
• Should you use Release Pipelines and YAML ones at the same time? or only pick one?

#2
  1. No
  2. Use YAML releases unless you specifically need features not available
#3

Release hub is “deprecated”. YAML is the future.

#4

That was also the feeling that I got from reading the documentation and examples online. Sadly the learning modules for AZ400 still cover the Releases extensive . I’m currently studying to get that certification

#5

The overall process, agent infrastructure, environments, policies etc and tasks are shared between the two. So there is a lot of overlap.

#6

And you need to know that whenever you want a manual intervention or “release gate” task, you still need o use the old releare.

#7

Okay so any Manual Intervention is not possible in YAML based pipelins. That’s a good one to know since the company would like it that customers have to “Check a box” in order to deploy from like acceptances to prod.

#8

Only manual approval between stages.

#9

Yeah, so that is possible, but you can’t halt mid-job and have a person review a generated SQL file before continuing.

#10

Stage Approvals work in .YAML

#11

Yes. well prehaps we could create a pipeline that starts with a stage approval

#12

Though once approved it won’t ask again in the same pipeline. So each stage would have to target different resources or environments

#13

And you could use this: but it requires way too much permissions to approve: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/manual-validation?view=azure-devops&tabs=yaml&WT.mc_id=DOP-MVP-5001511

#14

You need Queue Build permissions.

#15

This is the UI build equivalent: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/manual-intervention?view=azure-devops&WT.mc_id=DOP-MVP-5001511

#16

Yes, i already did some experiments with the Manual Intervention step

#17

That’s more for the Dev or Ops team todo validation. But not something you’d use for customers.

#18

Currently the customer approves a release by checking a little box in an small internal application that we host. Prehaps we could expand this application so it triggers an HTTP request that activates the build pipeline

#19

YAML also doesn’t have post-deployment “Acceptance” tracking.