✨*Question of the day* ✨ What do you like more, YAML or Classic pipelines? And why? 🆘 NEED HELP? 🆘 Book a 1:1 Consultation with CoderDave: geni.us/cdconsult We can talk about GitHub, Azure DevOps, or any other DevOps tool or project you need help with! 🙏🏻SUPPORT THE CHANNEL🙏🏻 Buy me a coffee: www.buymeacoffee.com/CoderDave PayPal me donation: paypal.me/dabenveg
Thanks! That’s a great reason, the Azure Pipelines Environments for Kubernetes are really insightful for that... I have a whole video about it, if you haven’t seen it yet
Thanks. Not yet, I was planning on making one like I’ve done for Github Actions but then I got very busy at work… however I do have a playlist about azure DevOps and another one for concepts around Pipelienes
Great video! Cleared up a lot for me. One thing I still want to know is how do you create a yaml just for your CD pipeline? If I go to Pipelines > Releases > "+ New release pipeline", it only opens with the classical editor. Because of this, I assumed if you wanted to do your CD pipeline in yaml, it would have to go in the same file as your CI.
Good question! Yes, for YAML both CI and CD are "in the same place" The Release Pipelines section is for the classic ones, from the UI. For YAML, you can either do CI and CD together in what is referred to as "multi-stage pipelines" (preferred) or you can split CI and CD in 2 different YAML files but then you'd need to "share" the artifact from one to another and trigger them properly. Tip: for CD, in the YAML file you should use a job of type "deployment" rather than just "job"
Dave, you are doing great job, clear explanation, lot of interesting videos - thanks! Just wanted to ask one question about Python package CI/CD - what would you recommend for such scenario? As for now we have a separate CI/CD packages, both are YAML pipes. Our CD task is building wheel package and deploying it onto Azure Artifacts Feed. Before I've seen this video, our CD pipeline was simple yaml pipeline with steps and task+scripts which were executing simple python commands (setup.py, wheel, twine upload etc). I'm not sure if I understand well, but based on this video: should we do build on each CI pipeline and publish wheel package as an artifact? Consequently should we change CD pipeline to deployment job and use artifact generated in CI pipeline?
Thanks Michal! :) The CI/CD of packages is always "borderline". On one hand, the cleanest way to do it (separation of concerns ) would be having a CI job that builds and test, and a CD job that grab the result of the build and pushes it as a package to the registry. On the other hand, since your CD job in this scenario would only have 1 step, it may not be worthy the extra latency of uploading and downloading the artifacts. Personally I would go for option 1 because I like to keep everything clean, but as I said we are borderline. If you instead need to publish the package to more than one registry or you want to promote it to different stages (dev, test, prod) then for sure I'd go with separate CI and CD. Hope this helps :)
hi Dave thank you for the video. I have a question. I am creating a Yaml Release pipeline. Converting from Classic Release pipelines to YAML Release pipeline. The first task for classic pipeline is to associate a Build Artifact so i am trying to do the same for Yaml pipeline as well. I see that there is a download Build artifacts Task that i can use. But i want to use steps.downloadBuild from Yaml Schema and it does not have much information how to specify the current build, build defintion, Artifact name, desitination directory. can you please help me to see if we do that without using the downlaod build artifact task ? is it possible or not ? any input is greatly appreciated
Hello Dave. I don't want to create a yaml pipeline for both build/release in the same. I want them to be separate and I want to know how to convert taks groups in to yaml pipelines and how to add pre and post deployment approvals?? any video that would be real help
yes, coming from classic pipelines (where you have separate build and release pipelines) it is very common to wanting to replicate the same behavior... unfortunately doing so in YAML pipelines is not straight forward, because YAML Pipelines have been designed from the ground up to be multi-stage, basically build and deploy in the same YAML. with that said, there is a way to achieve what you want. First, in your Build pipeline you need to add a task that publishes the artifact. be sure to use the "Publish build artifacts" task (PublishBuildArtifacts) and not the "Publish Pipeline Artifact" (PublishPipelineArtifact) one Then, in your Deploy pipeline you need to use the "Download build artifacts" (DownloadBuildArtifacts) task which allows you to specify a different build pipeline to download the artifact from. Finally, you need to trigger your Deploy pipeline when the Build pipeline completes. This happens automatically in Classic pipelines, but in YAML you need to do it yourself. To see how, you can check this other video I made where I explain how to do it: ruclips.net/video/o6fMncjlrW8/видео.html
@@CoderDave thank you so much. I have a couple of questions. Instead of using download build step. Can I use steps.downloadbuild to download build artifacts and just to be sure will Microsoft deprecated download build artifacts task any time soon ?
Hate YAML, I just find it so difficult. Love the classic approach. But I fear most employers are moving to YAML, and one day the option of even using classic will be gone. Deprecated!
YAML doesn’t have the friendliest syntax, but I think we can all agree it is very readable. Moreover, YAML is the industry standard for configuration as a code. Many people use YAML and many more will, but classic pipelines are there to stay, don’t worry 😉
Learned a lot from this Dave. Good job! I have a question though, let's say I have 2 apps. A front end app stored in Repo A and a back end app stored in Repo B. Currently, each app has its own classic build/release pipeline and we want to convert these classic pipelines to YAML pipelines. Would you recommend storing all YAML pipelines in one repository (Repo C?) or should we maintain one pipeline per app per repository?
Thank, I'm very happy to know that you've found this video insightful 😊 About your question, I'm a big fan of having each prohect pipelines in the same repo where the project lives. This would apply in the greatest majority of the cases (imho, of course). The only time when you may want to have all the pipelines in another repo is if you have a separate team working just on the pipelines and you don't want other people to have access to it. That said, I never go for the latter approach because it is not really "devopsy" :)
Appreciate giving your thoughts Dave. In our case, we have several apps (around 5) and each has its own classic CI/CD pipelines. Our goal is to convert each of them to YAML pipelines so we thought that putting all those in a single repository to make it more maintainable. Do you have any recommended community where the azure devops best practices are discussed?
Hi, you'd need to use the "Environment" features of YAML Pipelines. I would recommend you to watch my video about it here ruclips.net/video/gN4j65w7wIM/видео.html
Thanks! Not sure if you have seen that you can export the classic pipeline to yaml directly: Azure Pipelines Export to YAML. Finally! ruclips.net/video/PD0JHHw0Or4/видео.html
If you have a YAML file from another source, you can just commit it to your repo, then go to Azure Pipelines, New Pipeline, select your repo type and the repo, and finally pick "Existing Azure Pipeline YAML file" and select the yaml file you just commited :)
Hello@@CoderDave , 1 last question. And I m done asking dumb question. Will the procedure be the same for the release pipeline ( when you upload the yaml file ) ?
hehe no problem. If for release pipeline you mean a YAML Pipeline that does deployment then yes. But if we are talking “classic release pipelines “ (the ones with the nice UI) then unfortunately there is. I way to export/import them
![Azure Artifacts vs Build Artifacts vs Pipeline Artifacts: Difference EXPLAINED! [Azure DevOps]](/img/1.gif)
✨*Question of the day* ✨ What do you like more, YAML or Classic pipelines? And why?
🆘 NEED HELP? 🆘
Book a 1:1 Consultation with CoderDave: geni.us/cdconsult
We can talk about GitHub, Azure DevOps, or any other DevOps tool or project you need help with!
🙏🏻SUPPORT THE CHANNEL🙏🏻
Buy me a coffee: www.buymeacoffee.com/CoderDave
PayPal me donation: paypal.me/dabenveg
Great summary and comparison, Dave. Thanks!
Happy you found it helpful :)
Nice Video
Plan to use YAML, to get more granular level controls on Containers
Thanks! That’s a great reason, the Azure Pipelines Environments for Kubernetes are really insightful for that... I have a whole video about it, if you haven’t seen it yet
Great Explanation ... Thanks dave!!!
Glad you liked it!
Underrated video. Very clear explanation 👍
Thanks! Happy to be helpful ☺️
Great videos., thank you very much. Do you have a complete training course for azure devops pipeline?
Thanks. Not yet, I was planning on making one like I’ve done for Github Actions but then I got very busy at work… however I do have a playlist about azure DevOps and another one for concepts around Pipelienes
Great video! Cleared up a lot for me. One thing I still want to know is how do you create a yaml just for your CD pipeline? If I go to Pipelines > Releases > "+ New release pipeline", it only opens with the classical editor. Because of this, I assumed if you wanted to do your CD pipeline in yaml, it would have to go in the same file as your CI.
Good question! Yes, for YAML both CI and CD are "in the same place" The Release Pipelines section is for the classic ones, from the UI.
For YAML, you can either do CI and CD together in what is referred to as "multi-stage pipelines" (preferred) or you can split CI and CD in 2 different YAML files but then you'd need to "share" the artifact from one to another and trigger them properly.
Tip: for CD, in the YAML file you should use a job of type "deployment" rather than just "job"
@@CoderDave Thanks for the very clear explanations in your videos. How do you recommend "sharing" the artifact between pipelines?
Thanks! I've actually just published a video about Artifacts :) ruclips.net/video/WWCmEUCt3Cc/видео.html
How do you allow access to the system access token on the build pipeline jobs(non-classic)?
I'm not sure I know what you mean by "system access token"
Dave, you are doing great job, clear explanation, lot of interesting videos - thanks! Just wanted to ask one question about Python package CI/CD - what would you recommend for such scenario? As for now we have a separate CI/CD packages, both are YAML pipes. Our CD task is building wheel package and deploying it onto Azure Artifacts Feed.
Before I've seen this video, our CD pipeline was simple yaml pipeline with steps and task+scripts which were executing simple python commands (setup.py, wheel, twine upload etc).
I'm not sure if I understand well, but based on this video: should we do build on each CI pipeline and publish wheel package as an artifact? Consequently should we change CD pipeline to deployment job and use artifact generated in CI pipeline?
Thanks Michal! :) The CI/CD of packages is always "borderline". On one hand, the cleanest way to do it (separation of concerns ) would be having a CI job that builds and test, and a CD job that grab the result of the build and pushes it as a package to the registry. On the other hand, since your CD job in this scenario would only have 1 step, it may not be worthy the extra latency of uploading and downloading the artifacts.
Personally I would go for option 1 because I like to keep everything clean, but as I said we are borderline. If you instead need to publish the package to more than one registry or you want to promote it to different stages (dev, test, prod) then for sure I'd go with separate CI and CD.
Hope this helps :)
hi Dave thank you for the video. I have a question. I am creating a Yaml Release pipeline. Converting from Classic Release pipelines to YAML Release pipeline. The first task for classic pipeline is to associate a Build Artifact so i am trying to do the same for Yaml pipeline as well. I see that there is a download Build artifacts Task that i can use. But i want to use steps.downloadBuild from Yaml Schema and it does not have much information how to specify the current build, build defintion, Artifact name, desitination directory. can you please help me to see if we do that without using the downlaod build artifact task ? is it possible or not ? any input is greatly appreciated
Hello Dave. I don't want to create a yaml pipeline for both build/release in the same. I want them to be separate and I want to know how to convert taks groups in to yaml pipelines and how to add pre and post deployment approvals?? any video that would be real help
yes, coming from classic pipelines (where you have separate build and release pipelines) it is very common to wanting to replicate the same behavior... unfortunately doing so in YAML pipelines is not straight forward, because YAML Pipelines have been designed from the ground up to be multi-stage, basically build and deploy in the same YAML.
with that said, there is a way to achieve what you want.
First, in your Build pipeline you need to add a task that publishes the artifact. be sure to use the "Publish build artifacts" task (PublishBuildArtifacts) and not the "Publish Pipeline Artifact" (PublishPipelineArtifact) one
Then, in your Deploy pipeline you need to use the "Download build artifacts" (DownloadBuildArtifacts) task which allows you to specify a different build pipeline to download the artifact from.
Finally, you need to trigger your Deploy pipeline when the Build pipeline completes. This happens automatically in Classic pipelines, but in YAML you need to do it yourself. To see how, you can check this other video I made where I explain how to do it: ruclips.net/video/o6fMncjlrW8/видео.html
@@CoderDave thank you so much. I have a couple of questions. Instead of using download build step. Can I use steps.downloadbuild to download build artifacts and just to be sure will Microsoft deprecated download build artifacts task any time soon ?
Hate YAML, I just find it so difficult. Love the classic approach. But I fear most employers are moving to YAML, and one day the option of even using classic will be gone. Deprecated!
YAML doesn’t have the friendliest syntax, but I think we can all agree it is very readable. Moreover, YAML is the industry standard for configuration as a code. Many people use YAML and many more will, but classic pipelines are there to stay, don’t worry 😉
Learned a lot from this Dave. Good job! I have a question though, let's say I have 2 apps. A front end app stored in Repo A and a back end app stored in Repo B. Currently, each app has its own classic build/release pipeline and we want to convert these classic pipelines to YAML pipelines. Would you recommend storing all YAML pipelines in one repository (Repo C?) or should we maintain one pipeline per app per repository?
Thank, I'm very happy to know that you've found this video insightful 😊
About your question, I'm a big fan of having each prohect pipelines in the same repo where the project lives. This would apply in the greatest majority of the cases (imho, of course). The only time when you may want to have all the pipelines in another repo is if you have a separate team working just on the pipelines and you don't want other people to have access to it. That said, I never go for the latter approach because it is not really "devopsy" :)
Appreciate giving your thoughts Dave. In our case, we have several apps (around 5) and each has its own classic CI/CD pipelines. Our goal is to convert each of them to YAML pipelines so we thought that putting all those in a single repository to make it more maintainable. Do you have any recommended community where the azure devops best practices are discussed?
Hi,
I have doubt
How to implement Azure pipelines in High Environment Approvals through Yaml?
Hi, you'd need to use the "Environment" features of YAML Pipelines. I would recommend you to watch my video about it here ruclips.net/video/gN4j65w7wIM/видео.html
Great Video!
Thanks! ☺️
Thanks for the amazing video. I am working on converting 100s of classic pipelines to yaml pipeline through automation. Any help will be appreciated.
Thanks! Not sure if you have seen that you can export the classic pipeline to yaml directly: Azure Pipelines Export to YAML. Finally!
ruclips.net/video/PD0JHHw0Or4/видео.html
Thank you very much for your work! BTW, Is Classic pipelines still don't support container jobs?
Correct, Container Jobs are a feature of the YAML Pipelines only
How i import an yaml file for a build pipeline ?
If you have a YAML file from another source, you can just commit it to your repo, then go to Azure Pipelines, New Pipeline, select your repo type and the repo, and finally pick "Existing Azure Pipeline YAML file" and select the yaml file you just commited :)
@@CoderDave thank you sir. And 1 more comment . Lets say i have a yaml file which include both cicd (release + build ) is the procedure the same ?
No worries😉 yes, the procedure would be the same
Hello@@CoderDave , 1 last question. And I m done asking dumb question. Will the procedure be the same for the release pipeline ( when you upload the yaml file ) ?
hehe no problem. If for release pipeline you mean a YAML Pipeline that does deployment then yes. But if we are talking “classic release pipelines “ (the ones with the nice UI) then unfortunately there is. I way to export/import them
Great video!
Thanks!