Whats the difference between a build pipeline and a release pipeline in Azure DevOps?

Question

I have set up several multi-staged build pipelines in Azure DevOps by using .yaml files. I've read about the "Release Pipelines" available, and I'm wondering what the benefits of those are?

They seem to do the same, don't even offer YAML's support. So what's the main difference here? What can I do by using release pipelines, rather than usual build pipelines?

Sheepshanks

Answer 1

In Azure DevOps, before there was the multi stage yaml pipelines (now known as "Pipelines", you usually used the Build Pipeline to build / create your software binaries (e. g. dotnet publish or ng build --prod) and stored these artifacts in the Azure DevOps drop location.

Then you normally had a Release Pipeline that gets triggered with these build artifacts (software binaries) and deploys them to one or many stages.

The reason to separate these two pipelines (build and release) is that you want to build a specific version of your software only once and then use the same binaries in each of your target environment (e. g. dev / test / production).

With the new pipeline, you usually use the first Stage to build your artifacts, and the next Stages to deploy it - similar as before but in one module.

If you have previously used the build & release pipeline, you will see the old build definition inside the new Pipeline module, and the old release definition in the old release module. However, they never brought YAML to the Release Pipelines because they know that they will replace them with the multi stage pipelines anyway.

Conclusion: If you use the new multi-stage "Pipeline" module, you shouldn't use the classic Release Pipelines anymore.

Borneol

Thanks for clarification! Now this makes more sense to me. However, its strange that some of the official docs of Microsoft are still pointing to this "Release" pipelines, and a lot of tipps / tutorials i find online are using different UIs from different versions. – Sheepshanks

What about deployment groups? Previously they were only supported by release pipelines. – Reviviscence

@Reviviscence Sorry, I have no additional information about that one. – Borneol

@MartinBrandl, I'm pretty new to ADO - when you refer to the multi-stage pipeline model versus the classic Release Pipelines, are you saying we should use Pipelines => Pipelines for the build process, and use Pipelines => Releases to create the multi-stage deployments by adding the build artifacts to the multi-stage Release? – Porthole

@Porthole No. You shouldn't use the "Release" module anymore. Instead, you should write Multi-Stage Pipelines (inside the "Pipeline" module) where your first stage should be the "build" stage, and then you have one more deploy stages.... – Borneol

Also, one important pitfall I stumbled upon - if you decide to return to an older build on some environment and do Redeploy, it will actually use the cached version of your Release steps for that specific Release version. In case if you want to use the latest Release steps instead of the cached ones, you have to create a new Release and choose the old build artifact version from there. – Perdition

@MartinBrandl I am using a single Pipeline for building and testing (job 1) and then deploying (job 2) - relatively simple and don't see need for the 3rd level of grouping (stages) but would there be any practical reason to do so? Just want to make sure not missing anything here... – Petticoat

@MarkZ. Well, if you build your binaries in the first stage and deploy it to a certain environment in a second stage, you can always rerun the second stage to re-deploy a specific version. – Borneol

Answer 2

This question is a few years old and and theres still quite a gap betweens the functionalities when its about releasing versions.

i personally have two things i dont like about the modern pipelines approach (for releases) vs the "old" release pipelines:

1. the configuration of the modern pipelines is more complicated
2. the ui isnt as good for release management

for our scenario lately the release pipelines were still the better alternative. the ui and the accessibility of the configuration let us chose release pipelines for our releases and we kept the approach of having a build pipeline and a separate release pipeline.

You should consider the old release pipelines if you do not want to deploy every time to every environment and you have an approval process that also shouldnt be executed every time. you can implement that stuff in yaml but you cannot simply configure it. you have to configure the new pipeline in yaml yourself completely. the accessibility isnt as good.

You can see more easily which version is deployed. if you sometimes want to deploy older versions then release pipelines will show you clearly which version is deployed on which stage:

This is not the case with the modern pipelines. Thats how you see it in the overview:

the whole ui of the modern pipelines isnt made purely for releases. though you get a nice view of your stages in the details view of a pipeline...

... this view is even below the compiler warnings of the build!

the release pipelines are made for that process and you see that reflected in the ui. this is the details view of a single release and its always at the top of the page:

Rotund

Answer 3

Yaml is still developing, and some features in release pipeline cannot be completely replaced, such as:

• Queuing policies are not yet supported in YAML pipelines.
• Task groups are not supported in YAML pipelines. etc...

Similarly, some features in the build pipeline have not been completely replaced, such as

• Triggering on tags is not currently supported for Bitbucket Cloud repos.
• YAML PR triggers are only supported in GitHub and Bitbucket Cloud. etc...

So, with the development of yaml, its features will be more and more comprehensive, but now some features of release pipeline cannot be completely replaced, and release pipeline still has value.

Kotta

Although YAML PR trigger does not work for AzureRepos, you can set it up using build policies. – Diluvium