Menu
I am sort of new to azure devops and I had to build few builds and release pipelines.
I have done it with visual designer and it was smooth & easy, while using yaml is much more prone to mistakes.
If I work in a team that uses yaml , I do it in designer first and then copy the yaml.
Apart from saving to the repo automatically, why the pain ? why not just use the designer ?
Missing the obvious?
977
Many teams prefer to define their build and release pipelines using YAML (YAML Ain't Markup Language). This allows them to access the same pipeline features as those using the visual designer, but with a markup file that can be managed like any other source file.
The same definition applies to release pipelines, the difference is that the former are used generally to build applications and the latter to deploy them. On the other hand, YAML pipelines are set up using code on, you guessed it, a YAML file.
Azure Pipelines supports continuous integration (CI) and continuous delivery (CD) to continuously test, build, and deploy your code. You accomplish this by defining a pipeline. The latest way to build pipelines is with the YAML pipeline editor. You can also use Classic pipelines with the Classic editor.
Now with the launch of Azure DevOps, the service really encourages using YAML. In fact, if you start a new project, those feature flags are turned on by default.
However, if you always used to do this through UI, or you're just completely new to Azure DevOps, it could be a bit confusing.
We do have a detail reference guide including a catalog of all supported YAML capabilities, and the available options-- YAML schema reference
There are truly some benefits for using YAML, it meant you could use the same branching and code review practices for your build definitions as you did for your code. And it's very useful for handling multiple build definitions.
You could also take a look at this helpful blog here:
58
Because its not scalable, how do you manage hundreds of visual jobs? only by hand, yaml jobs can be mass edited, than can use templating\looping\if and so on, you can reuse them etc. I'd really wish they made yaml for releases, managing releases is a pain in Azure Devops right now, builds are easy. we've got yamls...
30
I had same issues with new yaml only way of doing things in DevOps. User should have a choice to switch between two. For script lovers, they can always copy the generated script and automate.
I stumbled upon (after lot of reading) the setting menu hidden on the yaml code generated. Click on the settings link and it open a details pane on the right of the page. Refer the attached image.
This is where you can provide additional details and settings value. Once saved, it reflected back in yaml script.
I hope this bridge the gap between two type of users. :)
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
