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?

Answer 1

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:

Answer 2

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.

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.