120

An yaml file is generated while you choose this option shown below:

enter image description here

In this yaml file, you can define an entire deployment cycle starting from restore -> build -> run tests -> publish and -> deploy to azure app service web app.

then, why there is the releases option? If i can define an entire lifecycle via the Pipelines -> Pipelines option, what is the purpose of the Pipelines -> Releases option?

enter image description here

blogs4t
  • 2,329
  • 5
  • 20
  • 33
  • 6
    Does the below answer could help you achieve what you want? If yes, you can accept the answer thus other SO users will be able to see whether the solution works. If you still facing some issues, feel free to leave comment here :-) – Frank Wang-MSFT Oct 28 '19 at 08:48

3 Answers3

136

Pipelines is a name in latest DevOps user interface for Builds. In old UI it's like this: enter image description here

It can be said that Pipeline(or Build, or Build Pipeline) represents CI (continuous integration) in Azure DevOps. Release represents CD(continuous delivery) in Azure DevOps. Pipeline usually takes code, builds it, tests and creates an artifact. Release takes the artifact and releases/deploys it.

The usage depends on your project.

If you have a small project and there is no need in Release features (e.g. pre-deployment conditions and approvals), then you can have Pipeline like you mentioned: restore -> build -> tests -> deploy and no need in Release.

If your project is big with a lot of developers contribution, it's good to have Pipeline which builds, runs unit tests, does other automation and results with artifact every time developer pushes to the common repo. So you can be sure all is settle and integration tests passed. Pipeline also can end up with release/deploy task to development environment/servers for internal work, usage, testing.

In large project you don't need to deploy every push to common repo. So you can settle a Release which will be responsible for deployment to production environment. It has features designed for this, like pre-approval, so everyone is agree it's the right build (or artifact) for production.

Anna
  • 2,988
  • 3
  • 15
  • 29
  • 4
    That's not exactly accurate, as pipelines (when specified as YAML files) also support release scenarios. – Daniel Mann Oct 28 '19 at 13:44
  • 17
    @DanielMann she didn't say the opposite, she is answering the wandering of the op, by explaining the difference between the two – AymenDaoudi Apr 07 '20 at 03:12
  • 3
    @AymenDaoudi Daniel is correct, this answer isn't accurate. The difference isn't one of "Continuous Integration" vs. "Continuous Delivery" but "Classic Experience" vs. "New Experience". Regardless of project size, it's best to do everything the exact same way. – Derek Greer Jul 21 '22 at 13:45
  • 1
    Still the best answer here.. just add one more detail.. Release happens to be still on Classic Editor experience. – ValaravausBlack Jan 30 '23 at 11:59
59

As noted in Microsoft docs, the "Releases" section is their "Classic editor" solution: Link

"Pipelines" section offer to create pipelines in two ways:

  1. YAML code
  2. Classic UI editor

What Classic basically means by them is the original way Azure DevOps pipelines are created. You build a pipeline by using a GUI editor in an interactive way. Pipeline created from YAML, with the help of the assistant is the newer way.

What "Pipelines" section mainly have that "Releases" doesn't is that by writing YAML code it enables you to configure your CI/CD strategy as code, where, the Pipeline definition lives alongside and together with your code.

Their newest learning resources also indicate to use YAML and create build and deployment stages in the same pipeline Deploy applications with Azure DevOps

I recommend:

  • If you prefer to use Classic UI editor use "Pipelines" section for builds and "Release" section for deployments;
  • If you prefer to use YAML, just use "Pipelines" section for builds and deployments and create a multistage pipeline.

Pipeline with multiple stages

Edit: Update May 11, 2020, Pipelines YAML CD features now generally available

Avagdar
  • 599
  • 4
  • 5
  • 57
    It is really misleading how they are naming things. – AymenDaoudi Apr 07 '20 at 03:05
  • 1
    With the new update (May 11, 2020), does it make sense to have a yaml for the CI part and another for the CD part? – JoDG Jul 19 '20 at 23:01
  • 1
    @JoDG It depends(TM) on your pipeline design and general workflow. Say you wish to deploy basic lambda functions. It'd make sense to have a single YAML definition for the entire build/test/deploy process as a multi-stage pipeline. On the other hand, say you're deploying larger microservices which are built differently, but deployed the same way. In that instance, it'd make sense to have a single "CD" pipeline that is triggered by the many "CI" build/test pipelines. – seeafish Aug 19 '20 at 17:28
  • 1
    To my understanding, both Build&Release pipelines can do the deployment. Hence, the choice between falls on the features that only Release supports. Such as "human validation before deployment", "scheduled release" etc. Correct me if I am wrong. – han shih Aug 06 '21 at 07:51
  • Right now I'm leaning towards YAML for deployment because I think it's the only option that supports newer tasks like this one https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/sql-azure-dacpac-deployment?view=azure-devops – Nick.Mc Dec 14 '21 at 12:24
  • 2
    "human validation before deployment" is now supported in YAML pipleines by linking your deploy to an environment, then securing that environment – Nick.Mc Jul 07 '22 at 01:42
3

A Release represents continuous delivery(CD) in Azure DevOps.

A pipeline usually takes code, builds it, tests, and creates an artifact. Release pipelines takes the artifact and deploys it.

Note : 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.

Abhiram Padhi
  • 69
  • 2