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
Comments
@IanKemp I agree that Classic is still the way to go since YAML is missing some important features. 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 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. |
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. |
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). |
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! |
@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). |
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. 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? |
Yeah, I think the yaml is pretty bizarre. I don't understand how a multibillion dollar multinational company could make standard a "pipeline builder" with zero tooling. |
@WilliamAntonRohm , I don't know that this issue shouldn't be discussed in the docs. 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. |
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.
The text was updated successfully, but these errors were encountered: