Azure Pipelines: Classic vs Yaml - Build and Release comparison

Поділитися
Вставка
  • Опубліковано 8 вер 2024

КОМЕНТАРІ • 46

  • @CoderDave
    @CoderDave  4 роки тому +5

    ✨*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

  • @reddymalathi5274
    @reddymalathi5274 2 місяці тому

    Great Explanation ... Thanks dave!!!

    • @CoderDave
      @CoderDave  2 місяці тому

      Glad you liked it!

  • @ReneKubicka
    @ReneKubicka Рік тому

    Great summary and comparison, Dave. Thanks!

    • @CoderDave
      @CoderDave  Рік тому

      Happy you found it helpful :)

  • @jaykumaranbu7173
    @jaykumaranbu7173 3 роки тому +1

    Nice Video
    Plan to use YAML, to get more granular level controls on Containers

    • @CoderDave
      @CoderDave  3 роки тому +1

      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

  • @saicharanyadavelli2317
    @saicharanyadavelli2317 3 роки тому

    Underrated video. Very clear explanation 👍

    • @CoderDave
      @CoderDave  3 роки тому

      Thanks! Happy to be helpful ☺️

  • @manueltuero3477
    @manueltuero3477 3 роки тому

    Great video!

  • @ericromano3964
    @ericromano3964 2 роки тому +1

    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.

    • @CoderDave
      @CoderDave  2 роки тому +2

      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"

    • @ericpoynter7427
      @ericpoynter7427 2 роки тому +1

      @@CoderDave Thanks for the very clear explanations in your videos. How do you recommend "sharing" the artifact between pipelines?

    • @CoderDave
      @CoderDave  2 роки тому

      Thanks! I've actually just published a video about Artifacts :) ua-cam.com/video/WWCmEUCt3Cc/v-deo.html

  • @michlimes
    @michlimes 3 роки тому +1

    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?

    • @CoderDave
      @CoderDave  3 роки тому +2

      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 :)

  • @joeb.1163
    @joeb.1163 Рік тому +1

    Great videos., thank you very much. Do you have a complete training course for azure devops pipeline?

    • @CoderDave
      @CoderDave  Рік тому

      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

  • @29Apocalypes
    @29Apocalypes 3 роки тому +1

    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?

    • @CoderDave
      @CoderDave  3 роки тому +2

      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" :)

    • @29Apocalypes
      @29Apocalypes 3 роки тому

      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?

  • @tigeressxxx
    @tigeressxxx Рік тому +1

    Thanks for your amazing videos!! How can we run automation tests in visual mode in azure classic pipeline? I don't see any option for visual mode in my setting :)

    • @CoderDave
      @CoderDave  Рік тому +1

      Thanks! Unfortunately, UI tests are not supported in CI/CD systems in general. AFAIK the only thing you can do is running UI tests via K6, because it doesn't actually run a browser so it is automatable on non-ui systems.

  • @user-tm6cd8sg5l
    @user-tm6cd8sg5l Рік тому

    Thank you very much for your work! BTW, Is Classic pipelines still don't support container jobs?

    • @CoderDave
      @CoderDave  Рік тому

      Correct, Container Jobs are a feature of the YAML Pipelines only

  • @saurabhraoot
    @saurabhraoot Рік тому +1

    Thanks for the amazing video. I am working on converting 100s of classic pipelines to yaml pipeline through automation. Any help will be appreciated.

    • @CoderDave
      @CoderDave  Рік тому

      Thanks! Not sure if you have seen that you can export the classic pipeline to yaml directly: Azure Pipelines Export to YAML. Finally!
      ua-cam.com/video/PD0JHHw0Or4/v-deo.html

  • @corrierobbertse1524
    @corrierobbertse1524 2 роки тому +1

    How do you allow access to the system access token on the build pipeline jobs(non-classic)?

    • @CoderDave
      @CoderDave  2 роки тому

      I'm not sure I know what you mean by "system access token"

  • @Chatsworth1979
    @Chatsworth1979 3 роки тому +2

    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!

    • @CoderDave
      @CoderDave  3 роки тому +2

      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 😉

  • @jayaramsv4658
    @jayaramsv4658 3 роки тому +1

    Hi,
    I have doubt
    How to implement Azure pipelines in High Environment Approvals through Yaml?

    • @CoderDave
      @CoderDave  3 роки тому +1

      Hi, you'd need to use the "Environment" features of YAML Pipelines. I would recommend you to watch my video about it here ua-cam.com/video/gN4j65w7wIM/v-deo.html

  • @krishnasaikoneru1634
    @krishnasaikoneru1634 2 роки тому +1

    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

    • @krishnasaikoneru1634
      @krishnasaikoneru1634 2 роки тому +1

      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

    • @CoderDave
      @CoderDave  2 роки тому

      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: ua-cam.com/video/o6fMncjlrW8/v-deo.html

    • @krishnasaikoneru1634
      @krishnasaikoneru1634 2 роки тому

      @@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 ?

  • @leiidincraiova3381
    @leiidincraiova3381 2 роки тому

    How i import an yaml file for a build pipeline ?

    • @CoderDave
      @CoderDave  2 роки тому +1

      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 :)

    • @leiidincraiova3381
      @leiidincraiova3381 2 роки тому

      @@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 ?

    • @CoderDave
      @CoderDave  2 роки тому

      No worries😉 yes, the procedure would be the same

    • @leiidincraiova3381
      @leiidincraiova3381 2 роки тому

      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 ) ?

    • @CoderDave
      @CoderDave  2 роки тому

      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

  • @amarul92
    @amarul92 3 роки тому

    Great Video!