Azure DevOps Pipelines Tutorial – Continuous Integration

    22
    16



    Get the source code: https://youtube.dotnetmicroservices.com/azurepipelines-tutorial-ci

    How to create a Continuous Integration Azure Pipeline to automatically build and test all changes to your GitHub repository. You will learn:
    – How to enable continuous integration (CI) with Azure Pipelines
    – What is a YAML based pipeline and why use it
    – How to create a pipeline that runs on any change to your GitHub repo
    – How diagnose and fix issues detected by the pipeline
    – How to report the status of the pipeline on GitHub

    My site: https://dotnetmicroservices.com
    Twitter: @julioc
    LinkedIn: https://www.linkedin.com/in/juliocasal

    #azuredevops #github #YAML

    source

    Previous articleSimplify Your Infrastructure Management Using AWS CloudFormation
    Next articleDemo: CI/CD with GitLab

    16 COMMENTS

    1. Again, so many than ks for those simple yet ueful videos. Telle Julio, the CI build succeeds (I use local azure devops server 2220), i get following warnings in spite of the fact that the project uses net5.0 as indicated in the csproj file, any idea? ##[warning]c:program filesdotnetsdk5.0.102SdksMicrosoft.NET.SdktargetsMicrosoft.NET.EolTargetFrameworks.targets(28,5):

      Warning NETSDK1138: The target framework 'netcoreapp3.0' is out of support and will not receive security updates in the future.

      Please refer to https://aka.ms/dotnet-core-support for more information about the support policy.

    2. Hi Julio,
      Thanks for this. Really helpful
      One question,
      I have a solution wich contains CRA (Creat-Ract-App) project and as the client and .NET core 3 as Api (backend)
      Project.
      I just wanty pipeline to build CRA and API project then deploy them into separate locations example:
      CPA to blob storage to host as static file and Api to app services.
      Can you please advice how you could handle this using YMAL?
      Thanks heaps!

    3. Julio, Quick Question. Like in this tutorial, I assume you induced some bugs which failed the code in one instance, and in another instance Unit Tests failed. I would assume in both those instances Azure DevOps should have rejected the checkin. Or because in this case SCM is Git, code gets checked in first and only then the build pipelines are triggered in Azure DevOps? In a real life case, if a Dev makes a change and breaks something, if the Unit Tests or something else fails on the build, should not the build faliure reject the checkin?