Use Azure to automatically generate a CI/CD pipeline to deploy an ASP.NET app

Last Update: 7/5/2017

This tutorial shows how to configure a continuous delivery (CD) workflow for Azure App Service by using Visual Studio Team Services. CD is a great option for projects that require multiple and frequent contributions to be integrated.

CD in Team Services simplifies setting up a robust deployment pipeline for your app to publish the most recent updates to Azure App Service. The pipeline can be configured to build, runs tests, and deploy to a staging slot and then to production.

Code

You must store your app's source code in a Team Services Git, GitHub, or any other Git repository to use Azure Continuous Delivery. Team Foundation Version Control (TFVC) repositories are not supported at present.

Carry out the following steps to create a simple .NET MVC app to deploy.

  1. Create a new ASP.NET Web Application project in Visual Studio, targeting .NET Framework 4.5.

  2. Choose the MVC project type and leave the other settings at their defaults.

  3. Wait until the sample application has been created, then save the solution.

  4. Commit the solution to your chosen repository.

For more information about publishing your project, see Get Started with Git and Team Services or Create a repo (GitHub).

Configure

  1. In the Azure portal, select your web app. If you haven't yet created a web app, do this now by choosing the "+" icon, selecting Web App from the Web + Mobile category, and providing a name and a resource group.

    Creating a new Azure web app

  2. In your app's menu blade, choose Continuous Delivery (Preview) and then choose Configure.

    Opening Azure Continuous Delivery configuration

  3. Select Choose repository and select the type of repository where you stored your app's source code. You have a choice of Visual Studio Team Services, GitHub or External Git (a Git type repository not hosted in Team Services or GitHub).

    Specifying the type of source code repository

  4. Select the project, repository, and branch to deploy from. When you're done, choose OK.

    Specifying details of the source repository and branch

    If you chose to use GitHub, complete the authorization steps. If you chose to use an external Git repository, enter the repository name, branch, and (if required) your credentials.

    If you encounter a service endpoint error while configuring Continuous Delivery, see Troubleshoot Azure Resource Manager service endpoints.

  5. Select Configure Continuous Delivery and choose the web application framework you used to develop your app. This choice influences the way that Azure Continuous Delivery builds and packages the app for deployment. At present, ASP.NET, ASP.NET Core, PHP, Python, and Node.js are supported. When you're done, choose OK.

    Specifying the app framework type

  6. Select Set up load test and decide if you want to run a load test on your app before deploying the latest changes to production. The default is NO. If you want to set up a load test (25 virtual users concurrently accessing the app for 60 seconds), choose YES then specify whether to use an existing Azure App Service instance, or create a new one in a new App Service plan. When you're done, choose OK.

    Specifying whether and how to run a load test before deployment

    The new Azure App Service instance is created at the lowest pricing tier possible. For example, if your current App Service is in the S2 Standard pricing tier, the new App Service Plan for the load test will use the S1 Standard pricing tier. Pricing details.

  7. Select Configure deployment and decide if you want to deploy your latest changes first to staging, and then promote to production. The default is NO. If you want to set this up, choose YES then specify whether you want to use an existing Azure App Service slot, or create a new one. When you're done, choose OK.

    Specifying whether and how to configure production deployment

    See this topic for information about Azure App Service staging environments.

Build and deploy

  1. Choose OK to create and execute the Continuous Delivery workflow.

    Completing the Continuous Delivery configuration

    The following sequence of events occurs:

    • Azure Continuous Delivery creates a build and a release definition in the Team Services account you specified, together with a service endpoint to connect to Azure.

    • If you chose to create a new Azure App Service instance for load tests, and/or a new slot for staging, these are created in your Azure subscription.

    • After setup has completed successfully, a build is triggered that builds and packages the application for deployment.

    • After the build has completed successfully, a new release is created and the deployment triggered.

    • If you chose to include a load test, the latest changes are first deployed to the Azure App Service you selected, and then the load test is executed after the deployment succeeds.

    • If you chose to use a staging slot, the latest changes are deployed to the staging slot and then a slot swap is performed to complete the continuous delivery workflow.

  2. After all these actions have completed, the Azure portal shows the results in the Activity Log.

    Viewing the Continuous Delivery log

  3. In the "Successfully set up Continuous Delivery..." item, choose the Build Definition link to open the project containing your app in Team Services, and see the summary for the build definition. Choose Edit to see the tasks that have been added and configured.

    Viewing the newly created build definition

    Different tasks are added to the build definition depending on the app framework you selected. For example, a Visual Studio Build task is added for ASP.NET apps, while a .NET Core task is used for ASP.NET Core apps.

  4. In the "Successfully set up Continuous Delivery..." item, choose the Release Definition link to open the project containing your app in Team Services, and see the list of releases for this definition. Choose Edit to see the tasks that have been added and configured.

    Viewing the Test environment in the newly created release definition

    The release definition that is created depends on whether you chose to include a load test and/or a staging deployment. If you chose either or both, your release definition will have two environments named Test and Production. As shown above, the Test environment has two tasks: Azure App Service Deploy deploys the app to the Azure App Service you selected for load testing, and Cloud-based Web Performance task execute the load test.

    The Production environment, shown below, has an Azure App Service Deploy task. If you chose to use a staging deployment, the latest changes are deployed to the staging slot and then an Azure App Service Manage task performs a slot swap between staging and production slots.

    Viewing the Production environment in the newly created release definition

    If you opted out of both load test and a staging deployment, your release definition will have a single environment with just one Azure App Service Deploy task to deploy the latest changes to your Azure App Service.

    There are also links in other items in the Activity Log that open commits, builds, build reports, releases, deployment slots, and the deployed app itself, in relevant windows or apps.

  5. Verify that continuous deployment is occurring from the repository containing your app by pushing a change to the repository. Your app should update to reflect the changes shortly after the push to the repository completes.

    You can stop a deployment to your Azure App Service by choosing Disconnect at the top of the Continuous Deployment blade. This deletes the Azure Continuous Delivery configuration in the Azure portal and turns off the build triggers in your Team Services account for this configuration.

    Stopping a deployment

    To ensure the build and release history is preserved, the build and release definitions are not deleted from Team Services when you disconnect.

Next steps

You can easily add another Azure App Service to the pipeline to validate your changes before they reach production. This validation can be by running load or functional tests at each step. Further customization can be through provisioning additional Azure resources, running custom scripts, or upgrading a database. In addition, you can extend this deployment automation to handle any other operations your app needs to execute during deployment. You can even choose to deploy automatically, or set up manual approval for any deployment to production.

Notes

The Azure Continuous Delivery feature is a preview version. You may encounter the following known issues:

Q&A

How do I create an ASP.NET 4 web app?

  1. In Visual Studio, connect to your team project.

  2. On the Team Explorer home page (Keyboard: Ctrl + 0, H), under Solutions, click New.

  3. Select the Web category under Visual C#.

  4. Select ASP.NET Web Application and click OK.

  5. Select MVC from the template list.

  6. Click Change Authentication, select No Authentication, and click OK.

  7. Optionally, set Add unit tests to create a unit test project for the application. Unit tests can be run automatically with every build as part of a release pipeline.

  8. Clear Host in the cloud and click OK.

  9. Commit and push (Git) or check in (TFVC) your code.

I use Team Foundation Server on-premises and I don't see some of these features. Why not?

Some of these features are available only on Visual Studio Team Services and not yet available on-premises. Some features are available on-premises if you have upgraded to the latest version of TFS.

Help and support