I am using azure build and release pipelines. I understand that build pipeline produces an artifact that can be used by release pipelines and deployment can be organized into stages with options to deploy/re-deploy stage.
However, I also notice that all tasks available in release pipeline are also available in the build pipeline. Also the documentation for build pipeline states that it can be used to build, test and deploy. So what exactly is the benefit of using release pipelines?
For classic UI-format build and release pipeline:
Usually we use Build Pipeline to build/test our project and output the tested software binaries.
Then we can use Release Pipeline to deploy the artifacts from Build Pipeline to more than one stages depending on we need. So that, we only need to run the Build Pipeline once to get the artifacts(containing the software binaries) and we can use Release Pipeline to reuse and deploy the artifacts to different environment. (Develop, Product...)
Of course we can use Build Pipeline to run some deploy tasks, and we can use Release Pipeline to run the build and test tasks. We can but we shouldn't(not recommended), configuring the Build and Release UI pipeline can make the workflow of how we build/test(more related to CI)=>deploy(more related to CD) better.
And if you're using Multi-stage pipeline, you don't need to use the Release(UI) Pipelines. You can define CI/CD steps in one xx.yml file.
The pipelines under "Pipelines -> Releases", are classic deployment pipelines made with the GUI.
The new YAML pipelines are always under "Pipelines -> Pipelines" and allow both build and deployment jobs: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops. By using deployment jobs instead of classic Releases, the deployments will show up under "Pipelines -> Environments".
So in this way it makes sense the same tasks are available on both sides since both allow defining deployment workflows. YAML pipelines do not have the same capabilities as classic Releases yet though, I think release gates was still missing.
It is the same tasks but not the same processes.
Nowadays, I would say Pipelines are responsible for Continuous Integration, and Release Pipelines are more about Continuous Delivery. When all deployment features will arrive to YAML pipelines it will not be the case.
As you said, Azure Release Pipelines can use and automatically trigger on result of YAML or classic pipelines and you can use different agents. Agent for YAML or classic pipelines need all tools to compile, test and assembly the code when Agent for Release, need the tools for deployment and correct access rights to target environment.
In Release pipelines you can organize your deployments by environments/stages more easily, add steps which could be launched separately with out need to relaunch the whole pipeline (like application recovery or switch to production).
The workflow of Release Pipelines is more visual than in YAML or Classic Build pipelines.
From my experience the main difference is in Approvals and Gates features, for now.
You can try to implement the whole CI/CD process just on YAML pipelines but it could be much easier to use both Azure Pipelines capabilities to separate the logic of CI and CD, at the moment, as deployment features of YAML pipelines are still in development.
in principle there isn't. its just that usually release pipelines are geared towards deploying stuff and build pipelines towards building stuff. jenkins, for example, only had builds. and you'd be releasing with builds. it really depends on the solution you are using. octopus cannot really build stuff, but can release stuff and got tools to make releasing easier.
in ADO you can have stages in release pipelines, so you can do promotes easily, you have approval gates, etc
