Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please explain why YAML pipelines are the default vs Classic #5114

Closed
IanKemp opened this issue Aug 2, 2019 — with docs.microsoft.com · 10 comments
Closed

Please explain why YAML pipelines are the default vs Classic #5114

IanKemp opened this issue Aug 2, 2019 — with docs.microsoft.com · 10 comments
Assignees
Labels
devops/prod devops-cicd/tech doc-enhancement Suggested addition or improvement to the article. Pri1

Comments

Copy link
Contributor

IanKemp commented Aug 2, 2019

The YAML pipelines flow is substandard in every way to the Classic flow. Classic is simpler, easier to setup, doesn't require me to write and test and debug a text file, and covers 99.99% of use cases, yet it is seemingly being sidelined in favour of YAML - why? What benefit(s) does YAML give over Classic, apart from the fact that you can version YAML (but you could probably implement pipeline versioning into Classic anyway)? How do I setup separate Build and Release pipelines in the YAML flow?

It seems that YAML pipelines were introduced as the Next Big Thing and made default without any consideration for those who are used to the Classic flow. If you want YAML to succeed and more importantly, for Classic users to migrate to it, you absolutely need a walkthrough document that takes a project with Classic build and release pipelines, and converts them it to the azure-pipelines.yaml format. Yes I know that theoretically this is as simple as copying the generated YAML from the various Classic pipeline phases, but you need to know that...

Furthermore, why are Release pipelines not being pushed to use a YAML file?


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

@Swimburger
Copy link

Swimburger commented Aug 7, 2019

@IanKemp I agree that Classic is still the way to go since YAML is missing some important features.
Some of these features are on the roadmap though (blog post).

As you mentioned YAML have the advantage of being part of your source code. In addition to that it's just a text file that I can more easily share with my team, or write about in blog posts.
I'm currently working on an Azure DevOps article, and it's so much easier to share the YAML file vs taking screenshots for every step to create the pipeline. This is also a huge benefit for open source projects to share their build/deployments with their community.

I think it's good YAML will become the standard but I agree that Microsoft may be jumping the gun here. For YAML to become the standard, the visual building interface and functionality should exceed Classic.
Especially when it comes to release pipelines YAML has a long way to go which is why I use YAML for builds, but classic for releases.

@WilliamAntonRohm WilliamAntonRohm added area - pipelines cba product-feedback Product-related feedback, as opposed to doc feedback labels Aug 7, 2019
@WilliamAntonRohm
Copy link
Contributor

It looks like you've encountered an issue with the product itself, rather than an issue with the documentation. To make sure it gets in front of the right people, please submit your bug here.

@gstevens-kyriba
Copy link

I totally concur on this feedback... Why mark Release Pipelines as (Classic) when there isnt a viable replacement yet?

@jedjohan
Copy link

I totally concur on this feedback... Why mark Release Pipelines as (Classic) when there isnt a viable replacement yet?

In my opinion YAML is very much a viable replacement now (since a few months back). Just doing "normal" devops stuff and multistage pipelines works great for both build and release (database, frontend and backend).

@StingyJack
Copy link
Contributor

YAML have the advantage of being part of your source code

this is not an advantage. It means you are locked in and inflexible at build time, and any change to a build process requires Yet Another Checkin. Its like manually updating version numbers in the repo, aka "version churn"

@ErrCode
Copy link

ErrCode commented Apr 15, 2020

YAML have the advantage of being part of your source code

this is not an advantage. It means you are locked in and inflexible at build time, and any change to a build process requires Yet Another Checkin. Its like manually updating version numbers in the repo, aka "version churn"

Firstly, I'd like to say I actually prefer and like the Classic interface.

That said, one potential advantage for 'YAML being part of the source code' is under this use case:

Say your source repo changes requires the build process to also be modified for it to work (e.g. let's say you switched your installer framework - you now have a whole bunch of new installer build config files that need to be used with a new setup builder).

With the Classic pipeline, there is a disconnect from the source repo. You'd have to keep in mind that after you modify your Classic pipeline to work for the new installer framework, then this pipeline will no longer be able to properly build your source from the repo history before the new installer framework changes.

You could keep the old Classic pipeline around to handle building your old installer binaries as well, but then you'd have to know this and keep track of it somewhere. That or you could introduce flow-splitting logic that detects new vs old and then handles either appropriately, but this would have automatically been taken care of had you used YAML and it had been tied in with your code repo in the first place.

If there is anyone with a better way to deal with this use case using the 'Classic pipeline', please do share as I'm very interested to learn and improve!

@StingyJack
Copy link
Contributor

@ErrCode - When I have to make something like an installer change like that, I will usually create a branch and let the prior installer tech EOL in and point the older build def at it. The new build def will be pointed at the current release branch.

If build time is not a significant consideration for you, build both installers in the same build and forego the switching. Then you wont have any "artifact regret" and can even A/B test the installers (if you care about that).

@zameb
Copy link

zameb commented Jun 8, 2020

YAML have the advantage of being part of your source code

this is not an advantage. It means you are locked in and inflexible at build time, and any change to a build process requires Yet Another Checkin. Its like manually updating version numbers in the repo, aka "version churn"

And I'll add that now you have to worry about conflicts and merges in the process itself. In a UI I don't care on how the process is represented at the server side.
You will be never sure if the previous commit(er) disabled some tests in favor of a disastrous code.

It is fine to have version control on the process itself, but I consider a error to mix very different things as if they were the same.

How will be an error (not matching opening and closing symbols, tabulation errors, etc.) file be reported?

@yringler
Copy link

yringler commented Feb 12, 2021

Yeah, I think the yaml is pretty bizarre.
(I mean, in general yaml is pretty bizzare, even on a good day.)
I found the tooling to be pretty much nonexistent, whether online or in vs code with the yaml schema. Markup will often be invalid until you finish typing - no autocomplete, so you have to copy things from your deep knowledge of ADO pipelines.
The docs - I thought I needed a deploy pipeline, because I'm deploying to a dev server? But no, maybe a regular?
I worked on it for a couple hours, gave up, and put together a working pipeline with the GUI in a few minutes.

I don't understand how a multibillion dollar multinational company could make standard a "pipeline builder" with zero tooling.
I'd love to see stats of which is more frequently used to create new pipelines (that remain in use for more then a week) (lets not count the dozen yaml things I tried making before I dropped it).

@yringler
Copy link

yringler commented Feb 12, 2021

@WilliamAntonRohm , I don't know that this issue shouldn't be discussed in the docs.
As some looking through the mammothly deep and lengthy documentation which describes setting up pipelines, a reasonable question to have answered in the docs is "Why am I doing this to myself, and not just using the GUI?"

Myself and a colleague of mine both independently devoted many hours to trying to set things up in yaml before giving up and using the GUI.

@WilliamAntonRohm WilliamAntonRohm added doc-enhancement Suggested addition or improvement to the article. and removed cba product-feedback Product-related feedback, as opposed to doc feedback labels Feb 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
devops/prod devops-cicd/tech doc-enhancement Suggested addition or improvement to the article. Pri1
Projects
None yet
Development

No branches or pull requests