{"id":36459,"date":"2019-04-23T00:40:29","date_gmt":"2019-04-23T07:40:29","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/premier-developer\/?p=36459"},"modified":"2019-04-19T07:52:23","modified_gmt":"2019-04-19T14:52:23","slug":"using-azure-devops-to-deploy-web-applications-to-virtual-machines","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/premier-developer\/using-azure-devops-to-deploy-web-applications-to-virtual-machines\/","title":{"rendered":"Using Azure DevOps to Deploy Web Applications to Virtual Machines"},"content":{"rendered":"

App Dev Manager Jafar Jaffery<\/a> explores how to use Azure DevOps to deploy apps to Virtual Machines.<\/p>\n

\n

Overview<\/h2>\n

In this post, I will cover a basic end-to-end example of deploying an ASP.NET MVC web application from source code to Production using Azure DevOps. The web app will be hosted within Windows Virtual Machines (VMs). While it\u2019s worth mentioning that hosting web applications using Azure PaaS offerings or via containers would be the preferred route for a variety of reasons, VMs are still widely used in many organizations. With that scenario in mind, this post is geared to helping you get started with streamlining your release process. As a note, much of this process translates easily to using Azure PaaS offerings.<\/p>\n

CI\/CD Pipeline<\/h2>\n

The diagram below outlines the CI\/CD (Continuous Integration\/Continuous Delivery) pipeline we\u2019ll be setting up. The CI\/CD pipeline is a practice used by DevOps teams for delivering code changes more frequently and reliably. This enables agile teams to shorten cycle times, improve quality, and deliver value faster. The pipeline below is not intended to be fully comprehensive (e.g., no UI testing, security scanning, load testing, etc.), but has the core components needed to get started. The only prerequisites needed here are your VMs, and an Azure DevOps<\/a> account (or alternatively, using Azure DevOps Server<\/a>, previously known as Team Foundation Server).<\/p>\n

\"C:\\Users\\jajaffer\\AppData\\Local\\Temp\\SNAGHTML12152547.PNG\"<\/p>\n

Continuous Integration – Code \/ Build \/ CI Trigger<\/h2>\n

Follow these steps to setup the build:<\/p>\n

    \n
  1. Go to Pipelines >> Builds >> New build pipeline\n\"C:\\Users\\jajaffer\\AppData\\Local\\Temp\\SNAGHTML12de2c2b.PNG\"<\/li>\n
  2. Select your Project \/ Repo \/ Default Branch<\/li>\n
  3. Select the ASP.NET template<\/li>\n
  4. Save the build<\/li>\n<\/ol>\n

    Once setup, the build should something like this:<\/p>\n\n\n\n
    \"C:\\Users\\jajaffer\\AppData\\Local\\Temp\\SNAGHTML1260ecb1.PNG\"<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    To enable the CI part of the pipeline, go to the Triggers tab in the build, and check the box for \u201cEnable continuous integration\u201d. The build will now be triggered whenever any code changes are committed to the repository for the branch specified. As a good general practice, you should have your CI\/CD commits done using Pull Requests<\/a> in conjunction with a branching strategy<\/a>.<\/p>\n

    \"C:\\Users\\jajaffer\\AppData\\Local\\Temp\\SNAGHTML126630b7.PNG\"<\/p>\n

    Continuous Delivery<\/h2>\n

    Deployment Groups<\/h2>\n

    A deployment group is a logical set of deployment target machines that have agents installed on each one. Deployment groups represent the physical environments; for example, “Dev”, “Test”, “UAT”, and “Production”. To setup a deployment group, follow these steps<\/a>. Once setup, this can be used within the release.<\/p>\n

    \"C:\\Users\\jajaffer\\AppData\\Local\\Temp\\SNAGHTML12acb43a.PNG\"<\/p>\n

    Release<\/h2>\n

    A release pipeline takes in the artifact created from the build and releases it through the various stages or environments. To create a new release pipeline, go to Pipelines >> Releases >> New release pipeline.<\/p>\n

    <\/p>\n

    From here, select the \u201cIIS website deployment\u201d template as this will get the basic tasks in place<\/p>\n

    Once completed using the steps outlined below, the release pipeline should look like this:<\/p>\n

    \"C:\\Users\\jajaffer\\AppData\\Local\\Temp\\SNAGHTML12d59800.PNG\"<\/p>\n

    Follow the steps shown in the diagram above:<\/p>\n

      \n
    1. Select the source build pipeline. This is build we created earlier.<\/li>\n
    2. Enable the continuous deployment trigger.<\/li>\n
    3. Name the stage to your first environment, which in our case is \u201cTesting\u201d.<\/li>\n
    4. Set the properties for the \u201cTesting\u201d deployment job & IIS tasks for that job.<\/li>\n
    5. Clone the Testing task:\n\"C:\\Users\\jajaffer\\AppData\\Local\\Temp\\SNAGHTML12e7e33b.PNG\"\nThen change the name of the stage to your second environment, which in our case is \u201cProduction\u201d.<\/li>\n
    6. Set the properties for the \u201cProduction\u201d deployment job & IIS tasks for that job.<\/li>\n
    7. Set the pre-deployment approvers for \u201cProduction\u201d as follows:\n\"C:\\Users\\jajaffer\\AppData\\Local\\Temp\\SNAGHTML12ee0358.PNG\"<\/li>\n<\/ol>\n

      Variable Substitution for Environment-Specific Values<\/h2>\n

      The final piece of the picture here is to ensure that we have the correct config values for each environment we deploy to. To do this, we\u2019ll use variable substitution, which is a built-in feature of Azure DevOps that facilitates substituting your environment-specific values without having to use any specialized tokes in your config files or resorting to creating\/maintaining transform files for each environment. In order to deploy the same package across multiple environments, you can use XML variable substitution<\/a>. In case your project has any JSON config files, you can also use JSON variable substitution<\/a>.<\/p>\n

      On-Premise VM Considerations<\/h2>\n

      For the purposes of this setup, VMs can be host in Azure or On-Premise. For VMs hosted in Azure, you can use hosted agents in Azure DevOps. In case the VMs are hosted on-premise, you\u2019ll have to setup self-hosted agents to provide Azure DevOps visibility to the VMs, as shown in the diagram below. You can get more information on agents in the MS Docs here<\/a>.<\/p>\n

      <\/p>\n

      Conclusion<\/h2>\n

      As I\u2019ve demonstrated here, Azure DevOps offers a robust & easy to set-up platform for your Pipelines. When you use this in unison with the other out-of-box components (Boards, Repos, Test Plans, Artifacts) along with the rich library of marketplace extensions (SonarQube, Docker, Chef, Jenkins, WhiteSource, Slack, Teams, Octopus, etc.), you get a complete DevOps setup. You can get more information on these Azure DevOps components here: https:\/\/azure.microsoft.com\/en-us\/services\/devops\/<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

      While it\u2019s worth mentioning that hosting web applications using Azure PaaS offerings or via containers would be the preferred route for a variety of reasons, VMs are still widely used in many organizations. With that scenario in mind, this post is geared to helping you get started with streamlining your release process. As a note, much of this process translates easily to using Azure PaaS offerings.<\/p>\n","protected":false},"author":582,"featured_media":36460,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[25,22],"tags":[2571,21,3,375],"class_list":["post-36459","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","category-devops","tag-azure-devops","tag-devops","tag-team","tag-virtual-machine"],"acf":[],"blog_post_summary":"

      While it\u2019s worth mentioning that hosting web applications using Azure PaaS offerings or via containers would be the preferred route for a variety of reasons, VMs are still widely used in many organizations. With that scenario in mind, this post is geared to helping you get started with streamlining your release process. As a note, much of this process translates easily to using Azure PaaS offerings.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts\/36459","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/users\/582"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/comments?post=36459"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts\/36459\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/media\/36460"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/media?parent=36459"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/categories?post=36459"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/tags?post=36459"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}