© Jeffrey Palermo 2019
J. Palermo.NET DevOps for Azurehttps://doi.org/10.1007/978-1-4842-5343-4_2

2. Zero to Azure in 60 Minutes

Jeffrey Palermo1 
(1)
Austin, TX, USA
 

—Contributed by Cam Soper and Scott Addie, © Microsoft

“I am very grateful for this chapter’s contribution to the book. If you, dear reader, are new to the Microsoft platform, to Azure, or to Visual Studio, this chapter will help you understand the building blocks we will be working with in this book. If you have never used Azure DevOps Services in any way, this chapter will introduce you to that product family. I thank Cam Soper and Scott Addie, members of the Microsoft documentation team, for the contribution of this chapter to the book”—Jeffrey Palermo

To give you a hint of the capabilities available to ASP.NET Core developers on Azure, let’s take a quick tour through Azure App Service and Azure DevOps.

Deploy an App to App Service

Azure App Service is Azure’s web hosting platform. Deploying a web app to Azure App Service can be done manually or by an automated process. This section of the guide discusses deployment methods that can be triggered manually, by script using the command line, or triggered manually using Visual Studio.

In this section, you’ll accomplish the following tasks:

  • Download and build the sample app.

  • Create an Azure App Service web app using the Azure Cloud Shell.

  • Deploy the sample app to Azure using Git.

  • Deploy a change to the app using Visual Studio.

  • Add a staging slot to the web app.

  • Deploy an update to the staging slot.

  • Swap the staging and production slots.

Download and Test the App

The app used in this guide is a pre-built ASP.NET Core app, Simple Feed Reader. It’s a Razor Pages app that uses the Microsoft.SyndicationFeed.ReaderWriter API to retrieve an RSS/Atom feed and display the news items in a list.

Feel free to review the code, but it’s important to understand that there’s nothing special about this app. It’s just a simple ASP.NET Core app for illustrative purposes.

From a command shell, download the code, build the project, and run it, as shown in Figure 2-1.

Note

Linux/macOS users should make appropriate changes for paths, for example, using forward slash (/) rather than back slash ().

  1. 1.
    Clone the code to a folder on your local machine.
    git clone https://github.com/Azure-Samples/simple-feed-reader/
     
  2. 2.
    Change your working folder to the simple-feed-reader folder that was created.
    cd .simple-feed-readerSimpleFeedReader
     
  3. 3.
    Restore the packages and build the solution.
    dotnet build
     
  4. 4.
    Run the app.
    dotnet run
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig1_HTML.jpg
    Figure 2-1

    Command Prompt- dotnet run

     
  5. 5.

    The dotnet run command is successful.

     
  6. 6.
    Open a browser and navigate to http://localhost:5000. The app allows you to type or paste a syndication feed URL and view a list of news items. Refer to Figure 2-2.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig2_HTML.jpg
    Figure 2-2

    Simple Feed Reader

     
  7. 7.

    The app displaying the contents of an RSS feed.

     
  8. 8.

    Once you’re satisfied the app is working correctly, shut it down by pressing Ctrl+C in the command shell.

     

Create the Azure App Service Web App

To deploy the app, you’ll need to create an App Service web app. After creation of the web app, you’ll deploy to it from your local machine using Git.
  1. 1.

    Sign in to the Azure Cloud Shell. Note: When you sign in for the first time, Cloud Shell prompts to create a storage account for configuration files. Accept the defaults or provide a unique name.

     
  2. 2.
    Use the Cloud Shell for the following steps:

    • Declare a variable to store your web app’s name. The name must be unique to be used in the default URL. Using the $RANDOM Bash function to construct the name guarantees uniqueness and results in the format webappname99999.

    webappname=mywebapp$RANDOM

    • Create a resource group. Resource groups provide a means to aggregate Azure resources to be managed as a group.

    az group create --location centralus --name AzureTutorial
    The az command invokes the Azure CLI. The CLI can be run locally but using it in the Cloud Shell saves time and configuration.
    • Create an App Service plan in the S1 tier. An App Service plan is a grouping of web apps that share the same pricing tier. The S1 tier isn’t free, but it’s required for the staging slots feature.
      az appservice plan create --name $webappname --resource-group AzureTutorial --sku S1
    • Create the web app resource using the App Service plan in the same resource group.
      az webapp create --name $webappname --resource-group AzureTutorial --plan $webappname
    • Set the deployment credentials. These deployment credentials apply to all the web apps in your subscription. Don’t use special characters in the user name.
      az webapp deployment user set --user-name REPLACE_WITH_USER_NAME --password REPLACE_WITH_PASSWORD
    • Configure the web app to accept deployments from local Git and display the Git deployment URL. Note this URL for reference later.
      echo Git deployment URL: $(az webapp deployment source config-local-git --name $webappname --resource-group AzureTutorial --query url --output tsv)

    • Display the web app URL. Browse to this URL to see the blank web app. Note this URL for reference later.

    echo Web app URL: http://$webappname.azurewebsites.net
     
  3. 3.
    Using a command shell on your local machine, navigate to the web app’s project folder (e.g., .simple-feed-readerSimpleFeedReader). Execute the following commands to set up Git to push to the deployment URL:

    • Add the remote URL to the local repository.

    git remote add azure-prod GIT_DEPLOYMENT_URL

    • Push the local master branch to the azure-prod remote’s master branch.

    git push azure-prod master

    You’ll be prompted for the deployment credentials you created earlier. Observe the output in the command shell. Azure builds the ASP.NET Core app remotely.

     
  4. 4.

    In a browser, navigate to the web app URL, and note the app has been built and deployed. Additional changes can be committed to the local Git repository with git commit. These changes are pushed to Azure with the preceding git push command.

     

Deployment with Visual Studio

Note

This section applies to Windows only. Linux and macOS users should make the change described in step 2 below. Save the file and commit the change to the local repository with git commit. Finally, push the change with git push, as in the first section.

The app has already been deployed from the command shell. Let’s use Visual Studio’s integrated tools to deploy an update to the app. Behind the scenes, Visual Studio accomplishes the same thing as the command-line tooling, but within Visual Studio’s familiar UI.
  1. 1.

    Open SimpleFeedReader.sln in Visual Studio.

     
  2. 2.

    In Solution Explorer, open Pages.cshtml. Change <h2>Simple Feed Reader</h2> to <h2>Simple Feed Reader - V2</h2>.

     
  3. 3.

    Press Ctrl+Shift+B to build the app.

     
  4. 4.
    In Solution Explorer, right-click the project, and click Publish, as shown in Figure 2-3.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig3_HTML.jpg
    Figure 2-3

    Right-click, Publish

     
  5. 5.

    Visual Studio can create a new App Service resource, but this update will be published over the existing deployment. In the Pick a publish target dialog, select App Service from the list on the left, and then select Existing. Click Publish.

     
  6. 6.

    In the App Service dialog, confirm that the Microsoft or organizational account used to create your Azure subscription is displayed in the upper right. If it’s not, click the drop-down and add it.

     
  7. 7.
    Confirm that the correct Azure Subscription is selected. For View, select Resource Group. Expand the AzureTutorial resource group, and then select the existing web app. Click OK. Refer to Figure 2-4.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig4_HTML.jpg
    Figure 2-4

    Publish App Service dialog

     
Visual Studio builds and deploys the app to Azure. Browse to the web app URL. Validate that the <h2> element modification is live. Refer to Figure 2-5.
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig5_HTML.jpg
Figure 2-5

The app with the changed title

Deployment Slots

Deployment slots support the staging of changes without impacting the app running in production. Once the staged version of the app is validated by a quality assurance team, the production and staging slots can be swapped. The app in staging is promoted to production in this manner. The following steps create a staging slot, deploy some changes to it, and swap the staging slot with production after verification.
  1. 1.

    Sign in to the Azure Cloud Shell, if not already signed in.

     
  2. 2.
    Create the staging slot.
    • Create a deployment slot with the name staging.
      az webapp deployment slot create --name $webappname --resource-group AzureTutorial --slot staging
    • Configure the staging slot to use deployment from local Git and get the staging deployment URL. Note this URL for reference later.
      echo Git deployment URL for staging: $(az webapp deployment source config-local-git --name $webappname --resource-group AzureTutorial --slot staging --query url --output tsv)
    • Display the staging slot’s URL. Browse to the URL to see the empty staging slot. Note this URL for reference later.
      echo Staging web app URL: http://$webappname-staging.azurewebsites.net
     
  3. 3.

    In a text editor or Visual Studio, modify Pages/Index.cshtml again so that the <h2> element reads <h2>Simple Feed Reader - V3</h2> and save the file.

     
  4. 4.
    Commit the file to the local Git repository, using either the Changes page in Visual Studio’s Team Explorer tab or by entering the following using the local machine’s command shell:
    git commit -a -m "upgraded to V3"
     
  5. 5.
    Using the local machine’s command shell, add the staging deployment URL as a Git remote, and push the committed changes:

    • Add the remote URL for staging to the local Git repository.

    git remote add azure-staging <Git_staging_deployment_URL>

    • Push the local master branch to the azure-staging remote’s master branch.

    git push azure-staging master

    Wait while Azure builds and deploys the app.

     
  6. 6.
    To verify that V3 has been deployed to the staging slot, open two browser windows. In one window, navigate to the original web app URL. In the other window, navigate to the staging web app URL. The production URL serves V2 of the app. The staging URL serves V3 of the app. Refer to Figure 2-6.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig6_HTML.jpg
    Figure 2-6

    Comparing the browser windows

     
  7. 7.
    In the Cloud Shell, swap the verified/warmed-up staging slot into production.
    az webapp deployment slot swap --name $webappname --resource-group AzureTutorial --slot staging
     
  8. 8.
    Verify that the swap occurred by refreshing the two browser windows. Refer to Figure 2-7.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig7_HTML.jpg
    Figure 2-7

    Comparing the browser windows after the swap

     

Summary

In this section, the following tasks were completed:

  • Downloaded and built the sample app.

  • Created an Azure App Service web app using the Azure Cloud Shell.

  • Deployed the sample app to Azure using Git.

  • Deployed a change to the app using Visual Studio.

  • Added a staging slot to the web app.

  • Deployed an update to the staging slot.

  • Swapped the staging and production slots.

In the next section, you’ll learn how to build a DevOps pipeline with Azure Pipelines.

Additional Reading

Continuous Integration and Deployment

In the previous chapter, you created a local Git repository for the Simple Feed Reader app. In this chapter, you’ll publish that code to a GitHub repository and construct an Azure DevOps Services pipeline using Azure Pipelines. The pipeline enables continuous builds and deployments of the app. Any commit to the GitHub repository triggers a build and a deployment to the Azure Web App’s staging slot.

In this section, you’ll complete the following tasks:

  • Publish the app’s code to GitHub.

  • Disconnect local Git deployment.

  • Create an Azure DevOps organization.

  • Create a team project in Azure DevOps Services.

  • Create a build definition.

  • Create a release pipeline.

  • Commit changes to GitHub, and automatically deploy to Azure.

  • Examine the Azure Pipelines pipeline.

Publish the App’s Code to GitHub

  1. 1.

    Open a browser window and navigate to https://github.com .

     
  2. 2.
    Click the + drop-down in the header, and select New repository (refer to Figure 2-8):
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig8_HTML.jpg
    Figure 2-8

    GitHub New Repository option

     
  3. 3.

    Select your account in the Owner drop-down, and enter simple-feed-reader in the Repository name text box.

     
  4. 4.

    Click the Create repository button.

     
  5. 5.

    Open your local machine’s command shell. Navigate to the directory in which the simple-feed-reader Git repository is stored.

     
  6. 6.

    Rename the existing origin remote to upstream. Execute the following command:

    git remote rename origin upstream
     
  1. 7.
    Add a new origin remote pointing to your copy of the repository on GitHub. Execute the following command:
    git remote add origin https://github.com/<GitHub_username>/simple-feed-reader/
     
  2. 8.

    Publish your local Git repository to the newly created GitHub repository. Execute the following command:

    git push -u origin master
     
  1. 9.

    Open a browser window and navigate to https://github.com/<GitHub_username>/simple-feed-reader/ . Validate that your code appears in the GitHub repository.

     

Disconnect Local Git Deployment

Remove the local Git deployment with the following steps. Azure Pipelines (an Azure DevOps Service) both replaces and augments that functionality.
  1. 1.
    Open the Azure portal, and navigate to the staging (mywebapp<unique_number>/staging) web app. The web app can be quickly located by entering staging in the portal’s search box (refer to Figure 2-9):
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig9_HTML.jpg
    Figure 2-9

    Staging web app search term

     
  2. 2.

    Click Deployment options. A new panel appears. Click Disconnect to remove the local Git source control configuration that was added in the previous chapter. Confirm the removal operation by clicking the Yes button.

     
  3. 3.

    Navigate to the mywebapp App Service. As a reminder, the portal’s search box can be used to quickly locate the App Service.

     
  4. 4.

    Click Deployment options. A new panel appears. Click Disconnect to remove the local Git source control configuration that was added in the previous chapter. Confirm the removal operation by clicking the Yes button.

     

Create an Azure DevOps Organization

  1. 1.

    Open a browser, and navigate to the Azure DevOps organization creation page.

     
  2. 2.

    Type a unique name into the Pick a memorable name text box to form the URL for accessing your Azure DevOps organization.

     
  3. 3.

    Select the Git radio button, since the code is hosted in a GitHub repository.

     
  4. 4.
    Click the Continue button. After a short wait, an account and a team project, named MyFirstProject, are created. Refer to Figure 2-10.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig10_HTML.jpg
    Figure 2-10

    Azure DevOps organization creation page

     
  5. 5.
    Open the confirmation email indicating that the Azure DevOps organization and project are ready for use. Click the Start your project button (refer to Figure 2-11):
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig11_HTML.jpg
    Figure 2-11

    Start your project button

     
  6. 6.

    A browser opens to <account_name>.visualstudio.​com. Click the MyFirstProject link to begin configuring the project’s DevOps pipeline.

     

Configure the Azure Pipelines Pipeline

There are three distinct steps to complete. Completing the steps in the following three sections results in an operational DevOps pipeline.

Grant Azure DevOps Access to the GitHub Repository

  1. 1.
    Expand the or build code from an external repository accordion. Click the Setup Build button (refer to Figure 2-12):
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig12_HTML.jpg
    Figure 2-12

    Setup Build button

     
  2. 2.
    Select the GitHub option from the Select a source section (refer to Figure 2-13):
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig13_HTML.jpg
    Figure 2-13

    Select a source – GitHub

     
  3. 3.
    Authorization is required before Azure DevOps can access your GitHub repository. Enter GitHub connection in the Connection name text box, as shown in Figure 2-14. For example:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig14_HTML.jpg
    Figure 2-14

    GitHub connection name

     
  4. 4.

    If two-factor authentication is enabled on your GitHub account, a personal access token is required. In that case, click the Authorize with a GitHub personal access token link. See the official GitHub personal access token creation instructions for help. Only the repo scope of permissions is needed. Otherwise, click the Authorize using OAuth button.

     
  5. 5.

    When prompted, sign in to your GitHub account. Then select Authorize to grant access to your Azure DevOps organization. If successful, a new service endpoint is created.

     
  6. 6.

    Click the ellipsis button next to the Repository button. Select the /simple-feed-reader repository from the list. Click the Select button.

     
  7. 7.

    Select the master branch from the Default branch for manual and scheduled builds drop-down. Click the Continue button. The template selection page appears.

     

Create the Build Definition

  1. 1.
    From the template selection page, enter ASP.NET Core in the search box, as shown in Figure 2-15:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig15_HTML.jpg
    Figure 2-15

    ASP.NET Core search on template page

     
  2. 2.

    The template search results appear. Hover over the ASP.NET Core template, and click the Apply button.

     
  3. 3.

    The Tasks tab of the build definition appears. Click the Triggers tab.

     
  4. 4.
    Check the Enable continuous integration box. Under the Branch filters section, confirm that the Type drop-down is set to Include. Set the Branch specification drop-down to master, as shown in Figure 2-16.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig16_HTML.jpg
    Figure 2-16

    Enable continuous integration settings

    These settings cause a build to trigger when any change is pushed to the master branch of the GitHub repository. Continuous integration is tested in the Commit changes to GitHub and automatically deploy to Azure section.

     
  1. 5.
    Click the Save & queue button, and select the Save option, as shown in Figure 2-17:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig17_HTML.jpg
    Figure 2-17

    Save button

     
  2. 6.
    The following modal dialog appears, as shown in Figure 2-18:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig18_HTML.jpg
    Figure 2-18

    Save build definition – modal dialog

    Use the default folder of and click the Save button.

     

Create the Release Pipeline

  1. 1.
    Click the Releases tab of your team project. Click the New pipeline button. Refer to Figure 2-19.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig19_HTML.jpg
    Figure 2-19

    Releases tab – new definition button

    The template selection pane appears.

     
  1. 2.
    From the template selection page, enter App Service in the search box, as shown in Figure 2-20:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig20_HTML.jpg
    Figure 2-20

    Release pipeline template search box

     
  2. 3.
    The template search results appear. Hover over the Azure App Service Deployment with Slot template, and click the Apply button. The Pipeline tab of the release pipeline appears, as shown in Figure 2-21.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig21_HTML.jpg
    Figure 2-21

    Release pipeline tab

     
  3. 4.
    Click the Add button in the Artifacts box. The Add artifact panel appears, as shown in Figure 2-22:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig22_HTML.jpg
    Figure 2-22

    Release pipeline –Add artifact panel

     
  4. 5.

    Select the Build tile from the Source type section. This type allows for the linking of the release pipeline to the build definition.

     
  5. 6.

    Select MyFirstProject from the Project drop-down.

     
  6. 7.

    Select the build definition name, MyFirstProject-ASP.NET Core-CI, from the Source (Build definition) drop-down.

     
  7. 8.

    Select Latest from the Default version drop-down. This option builds the artifacts produced by the latest run of the build definition.

     
  8. 9.

    Replace the text in the Source alias text box with Drop.

     
  9. 10.

    Click the Add button. The Artifacts section updates to display the changes.

     
  10. 11.
    Click the lightning bolt icon to enable continuous deployments, as shown in Figure 2-23:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig23_HTML.jpg
    Figure 2-23

    Release pipeline artifacts – lightning bolt icon

    With this option enabled, a deployment occurs each time a new build is available.

     
  1. 12.

    A Continuous deployment trigger panel appears to the right. Click the toggle button to enable the feature. It isn’t necessary to enable the Pull request trigger.

     
  2. 13.

    Click the Add drop-down in the Build branch filters section. Choose the Build Definition’s default branch option. This filter causes the release to trigger only for a build from the GitHub repository’s master branch.

     
  3. 14.

    Click the Save button. Click the OK button in the resulting Save modal dialog.

     
  4. 15.
    Click the Environment 1 box. An Environment panel appears to the right. Change the Environment 1 text in the Environment name text box to Production, as shown in Figure 2-24.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig24_HTML.jpg
    Figure 2-24

    Release pipeline – Environment name text

     
  5. 16.
    Click the 1 phase, 2 tasks link in the Production box, as shown in Figure 2-25:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig25_HTML.jpg
    Figure 2-25

    Release pipeline – production environment link.png

    The Tasks tab of the environment appears.

     
  1. 17.

    Click the Deploy Azure App Service to Slot task. Its settings appear in a panel to the right.

     
  2. 18.

    Select the Azure subscription associated with the App Service from the Azure subscription drop-down. Once selected, click the Authorize button.

     
  3. 19.

    Select web app from the App type drop-down.

     
  4. 20.

    Select mywebapp/ from the App service name drop-down.

     
  5. 21.

    Select AzureTutorial from the Resource group drop-down.

     
  6. 22.

    Select staging from the Slot drop-down.

     
  7. 23.

    Click the Save button.

     
  8. 24.
    Hover over the default release pipeline name. Click the pencil icon to edit it. Use MyFirstProject-ASP.NET Core-CD as the name, as shown in Figure 2-26.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig26_HTML.jpg
    Figure 2-26

    Release pipeline name

     
  9. 25.

    Click the Save button.

     

Commit Changes to GitHub and Automatically Deploy to Azure

  1. 1.

    Open SimpleFeedReader.sln in Visual Studio.

     
  2. 2.

    In Solution Explorer, open Pages.cshtml. Change <h2>Simple Feed Reader - V3</h2> to <h2>Simple Feed Reader - V4</h2>.

     
  3. 3.

    Press Ctrl+Shift+B to build the app.

     
  4. 4.

    Commit the file to the GitHub repository. Use either the Changes page in Visual Studio’s Team Explorer tab, or execute the following using the local machine’s command shell:

    git commit -a -m "upgraded to V4"
     
  5. 5.

    Push the change in the master branch to the origin remote of your GitHub repository:

    git push origin master
    The commit appears in the GitHub repository’s master branch, as shown in Figure 2-27:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig27_HTML.jpg
    Figure 2-27

    GitHub commit in master branch

    The build is triggered, since continuous integration is enabled in the build definition’s Triggers tab, as shown in Figure 2-28:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig28_HTML.jpg
    Figure 2-28

    Enable continuous integration

     
  1. 6.
    Navigate to the Queued tab of the Azure Pipelines ➤ Builds page in Azure DevOps Services. The queued build shows the branch and commit that triggered the build, as shown in Figure 2-29:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig29_HTML.jpg
    Figure 2-29

    Queued build

     
  2. 7.
    Once the build succeeds, a deployment to Azure occurs. Navigate to the app in the browser. Notice that the “V4” text appears in the heading, as shown in Figure 2-30:
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig30_HTML.jpg
    Figure 2-30

    Updated app

     

Examine the Azure Pipelines pipeline

Build definition

A build definition was created with the name MyFirstProject-ASP.NET Core-CI. Upon completion, the build produces a .zip file including the assets to be published. The release pipeline deploys those assets to Azure.

The build definition’s Tasks tab lists the individual steps being used. There are five build tasks, as shown in Figure 2-31.
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig31_HTML.jpg
Figure 2-31

Build definition tasks

  1. 1.

    Restore: Executes the dotnet restore command to restore the app’s NuGet packages. The default package feed used is nuget.​org.

     
  2. 2.

    Build: Executes the dotnet build --configuration release command to compile the app’s code. This --configuration option is used to produce an optimized version of the code, which is suitable for deployment to a production environment. Modify the BuildConfiguration variable on the build definition’s Variables tab if, for example, a debug configuration is needed.

     
  3. 3.

    Test: Executes the dotnet test --configuration release --logger trx --results-directory <local_path_on_build_agent> command to run the app’s unit tests. Unit tests are executed within any C## project matching the **/*Tests/*.csproj glob pattern. Test results are saved in a .trx file at the location specified by the --results-directory option. If any tests fail, the build fails and isn’t deployed.

    Note To verify the unit tests work, modify SimpleFeedReader.Tests.cs to purposefully break one of the tests. For example, change Assert.True(result.Count > 0); to Assert.False(result.Count > 0); in the Returns_News_Stories_Given_Valid_Uri method. Commit and push the change to GitHub. The build is triggered and fails. The build pipeline status changes to failed. Revert the change, commit, and push again. The build succeeds.

     
  4. 4.

    Publish: Executes the dotnet publish --configuration release --output <local_path_on_build_agent> command to produce a .zip file with the artifacts to be deployed. The --output option specifies the publish location of the .zip file. That location is specified by passing a predefined variable named $(build.artifactstagingdirectory). That variable expands to a local path, such as ∗c:_work, on the build agent.

     
  5. 5.

    Publish Artifact: Publishes the .zip file produced by the Publish task. The task accepts the .zip file location as a parameter, which is the predefined variable $(build.artifactstagingdirectory). The .zip file is published as a folder named drop.

     
Click the build definition’s Summary link to view a history of builds with the definition, as shown in Figure 2-32:
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig32_HTML.jpg
Figure 2-32

Build definition history

On the resulting page, click the link corresponding to the unique build number, as shown in Figure 2-33:
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig33_HTML.jpg
Figure 2-33

Build definition summary page

A summary of this specific build is displayed. Click the Artifacts tab, and notice the drop folder produced by the build is listed, as shown in Figure 2-34:
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig34_HTML.jpg
Figure 2-34

Build definition artifacts – drop folder

Use the Download and Explore links to inspect the published artifacts.

Release Pipeline

A release pipeline was created with the name MyFirstProject-ASP.NET Core-CD, as shown in Figure 2-35:
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig35_HTML.jpg
Figure 2-35

Release pipeline overview

The two major components of the release pipeline are the Artifacts and the Environments. Clicking the box in the Artifacts section reveals the following panel, as shown in Figure 2-36:
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig36_HTML.jpg
Figure 2-36

Release pipeline artifacts

The Source (Build definition) value represents the build definition to which this release pipeline is linked. The .zip file produced by a successful run of the build definition is provided to the Production environment for deployment to Azure. Click the 1 phase, 2 tasks link in the Production environment box to view the release pipeline tasks, as shown in Figure 2-37:
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig37_HTML.jpg
Figure 2-37

Release pipeline tasks

The release pipeline consists of two tasks: Deploy Azure App Service to Slot and Manage Azure App Service – Slot Swap. Clicking the first task reveals the following task configuration, as shown in Figure 2-38:
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig38_HTML.jpg
Figure 2-38

Release pipeline deploy task

The Azure subscription, service type, web app name, resource group, and deployment slot are defined in the deployment task. The Package or folder text box holds the .zip file path to be extracted and deployed to the staging slot of the mywebapp<unique_number> web app.

Clicking the slot swap task reveals the following task configuration, as shown in Figure 2-39:
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig39_HTML.jpg
Figure 2-39

Release pipeline slot swap task

The subscription, resource group, service type, web app name, and deployment slot details are provided. The Swap with Production check box is checked. Consequently, the bits deployed to the staging slot are swapped into the production environment.

Additional Reading

  • Create your first pipeline with Azure Pipelines

  • Build and .NET Core project

  • Deploy a web app with Azure Pipelines

Monitor and Debug

Having deployed the app and built a DevOps pipeline, it’s important to understand how to monitor and troubleshoot the app.

In this section, you’ll complete the following tasks:

  • Find basic monitoring and troubleshooting data in the Azure portal.

  • Learn how Azure Monitor provides a deeper look at metrics across all Azure services.

  • Connect the web app with Application Insights for app profiling.

  • Turn on logging and learn where to download logs.

  • Stream logs in real time.

  • Learn where to set up alerts.

  • Learn about remote debugging Azure App Service web apps.

Basic Monitoring and Troubleshooting

App Service web apps are easily monitored in real time. The Azure portal renders metrics in easy-to-understand charts and graphs.

  1. 1.

    Open the Azure portal, and then navigate to the mywebapp<unique_number> App Service.

     
  2. 2.
    The Overview tab displays useful ”at-a-glance” information, including graphs displaying recent metrics, as shown in Figure 2-40.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig40_HTML.jpg
    Figure 2-40

    Overview panel

     

  • Http 5xx: Count of server-side errors, usually exceptions in ASP.NET Core code.

  • Data In: Data ingress coming into your web app.

  • Data Out: Data egress from your web app to clients.

  • Requests: Count of HTTP requests.

  • Average Response Time: Average time for the web app to respond to HTTP requests.

Several self-service tools for troubleshooting and optimization are also found on this page, as shown in Figure 2-41.
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig41_HTML.jpg
Figure 2-41

Self-service tools

  • Diagnose and solve problems is a self-service troubleshooter.

  • Application Insights is for profiling performance and app behavior, and is discussed later in this section.

  • App Service Advisor makes recommendations to tune your app experience.

Advanced Monitoring

Azure Monitor is the centralized service for monitoring all metrics and setting alerts across Azure services. Within Azure Monitor, administrators can granularly track performance and identify trends. Each Azure service offers its own set of metrics to Azure Monitor.

Profile with Application Insights

Application Insights is an Azure service for analyzing the performance and stability of web apps and how users use them. The data from Application Insights is broader and deeper than that of Azure Monitor. The data can provide developers and administrators with key information for improving apps. Application Insights can be added to an Azure App Service resource without code changes.
  1. 1.

    Open the Azure portal, and then navigate to the mywebapp<unique_number> App Service.

     
  2. 2.
    From the Overview tab, click the Application Insights tile, as shown in Figure 2-42.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig42_HTML.jpg
    Figure 2-42

    Application Insights tile

     
  3. 3.
    Select the Create new resource radio button. Use the default resource name and select the location for the Application Insights resource. The location doesn’t need to match that of your web app, as shown in Figure 2-43.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig43_HTML.jpg
    Figure 2-43

    Application Insights setup

     
  4. 4.

    For Runtime/Framework , select ASP.NET Core. Accept the default settings.

     
  5. 5.

    Select OK. If prompted to confirm, select Continue.

     
  6. 6.
    After the resource has been created, click the name of Application Insights resource to navigate directly to the Application Insights page, as shown in Figure 2-44.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig44_HTML.jpg
    Figure 2-44

    New Application Insights resource is ready

     
As the app is used, data accumulates. Select Refresh to reload the blade with new data, as shown in Figure 2-45.
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig45_HTML.jpg
Figure 2-45

Application Insights overview tab

Application Insights provides useful server-side information with no additional configuration. To get the most value from Application Insights, instrument your app with the Application Insights SDK. When properly configured, the service provides end-to-end monitoring across the web server and browser, including client-side performance. For more information, see the Application Insights documentation.

Logging

Web server and app logs are disabled by default in Azure App Service. Enable the logs with the following steps:
  1. 1.

    Open the Azure portal, and navigate to the mywebapp<unique_number> App Service.

     
  2. 2.
    In the menu to the left, scroll down to the Monitoring section. Select Diagnostics logs, as shown in Figure 2-46.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig46_HTML.jpg
    Figure 2-46

    Diagnostic logs link

     
  3. 3.

    Turn on Application Logging (Filesystem). If prompted, click the box to install the extensions to enable app logging in the web app.

     
  4. 4.

    Set Web server logging to File System.

     
  5. 5.

    Enter the Retention Period in days. For example, 30.

     
  6. 6.

    Click Save.

     

ASP.NET Core and web server (App Service) logs are generated for the web app. They can be downloaded using the FTP/FTPS information displayed. The password is the same as the deployment credentials created earlier in this guide. The logs can be streamed directly to your local machine with PowerShell or Azure CLI. Logs can also be viewed in Application Insights.

Log Streaming

App and web server logs can be streamed in real time through the portal.
  1. 1.

    Open the Azure portal, and navigate to the mywebapp<unique_number> App Service.

     
  2. 2.
    In the menu to the left, scroll down to the Monitoring section and select Log stream, as shown in Figure 2-47.
    ../images/488730_1_En_2_Chapter/488730_1_En_2_Fig47_HTML.jpg
    Figure 2-47

    Log stream link

     

Logs can also be streamed via Azure CLI or Azure PowerShell, including through the Cloud Shell.

Alerts

Azure Monitor also provides real-time alerts based on metrics, administrative events, and other criteria.

Note

Currently alerting on web app metrics is only available in the Alerts (classic) service.

The Alerts (classic) service can be found in Azure Monitor or under the Monitoring section of the App Service settings, as shown in Figure 2-48.
../images/488730_1_En_2_Chapter/488730_1_En_2_Fig48_HTML.jpg
Figure 2-48

Alerts (classic) link

Live Debugging

Azure App Service can be debugged remotely with Visual Studio when logs don’t provide enough information. However, remote debugging requires the app to be compiled with debug symbols. Debugging shouldn’t be done in production, except as a last resort.

Conclusion

In this section, you completed the following tasks:

  • Find basic monitoring and troubleshooting data in the Azure portal.

  • Learn how Azure Monitor provides a deeper look at metrics across all Azure services.

  • Connect the web app with Application Insights for app profiling.

  • Turn on logging and learn where to download logs.

  • Stream logs in real time.

  • Learn where to set up alerts.

  • Learn about remote debugging Azure App Service web apps.

Additional Reading

Wrap Up

With Azure App Service and Azure DevOps, ASP.NET Core developers have powerful, professional-grade tools to build business-critical application.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.139.238.76