Automatically generate a CI/CD pipeline to deploy an ASP.NET app

[ad_1]


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

CD in VSTS 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
VSTS 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 VSTS
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 VSTS, GitHub or External Git
    (a Git type repository not hosted in VSTS 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 VSTS 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 VSTS, 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 VSTS, 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 VSTS
    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 VSTS 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:

  • If you do not have relevant permission to create build and release definitions
    in the VSTS account, the Continuous Delivery configuration will fail
    with an appropriate error message. See
    Manage users and access in VSTS.

  • Continuous Delivery supports only applications developed by using
    ASP.NET and ASP.NET Core.

  • If you encounter the error “Failed to create an Azure service connection”
    while deploying to Azure App Service, see
    Troubleshoot Azure Resource Manager service endpoints.

  • There is a known issue where users are able to see their Visual Studio Team
    Services account information within the Azure classic portal,
    but not in the Azure dashboard. You may see a
    “No accounts found” message in this situation. To resolve this, you can
    configure your VSTS account to be backed by an
    Azure Active Directory (AAD) instance. For information on how to do this, see
    VSTS – Access with Azure Active Directory.

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 TFS on-premises and I don’t see some of these features. Why not?

Some of these features are available only on
VSTS
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

[ad_2]

source_link
https://www.asp.net