In this lab we will create a new Azure DevOps project and configure it to allow us build and deploy our container image. We will also deploy an Azue virtual machine to use as our Azure DevOps build agent. We will then create build and release pipelines and deploy our application to a test environment, performing a smoke test on the container.

DevOps MPP Course Source

Pre-requisites:

  • An Azure DevOps account
  • Visual Studio 2017 (we will add Docker support to the PartsUnlimited application using Visual Studio 2017. If you do not have Visual Studio 2017, VS2017 commuity edition is available from https://visualstudio.microsoft.com/)
  • You require a Build agent; there are several options in VSTS. However, in this exercise we will deploy a container to the build agent and view the output so we require containers to be available on the virtual machine and thus nested virtualization capability. For this exercise you have two options, the steps in the lab will be based on the Azure virtual machine scenario, but you can choose either one.
    • An Azure Virtual machine
      • This will require an Azure Subscription; details on how to set up a free Azure subscription are available at https://azure.microsoft.com/en-us/free/
      • Our deployment scripts for the build agent wil use the image Windows Server 2016 Datacenter with Containers
      • You will also need to follow the steps below to install and configure the build agent which uses chocolatey package manager in a custom script that installs various required software on the build agent VM.
    • A local Windows 10 environment
      • The steps for installing and configuring the build agent can be performed on the Windows 10 client as well as the Azure virtual machine.
  • An Azure Container Registry
    • You will need an Azure Container registry, if you do not have one you can follow the steps to create an Azure Container Regiistry in the lab Working with Containers
    • This requires an Azure subscription. It can be set up using the free Azure subscription being used for the Azure virtual machine above.

Lab Tasks:

  • Task 1: Deploy a virtual machine to Azure to use as an Azure DevOps build agent
  • Task 2. Create a new Azure DevOps Project
  • Task 3. Create Git repo and Import PartsUnlimited git repo
  • Task 4. Create a Personal Access Token (PAT)
  • Task 5. Create a Service Connection in Azure DevOps
  • Task 6. Add Docker support to the PartsUnlimited application using Visual Studio 2017
  • Task 7. Create Azure Container Registry
  • Task 8: Install and configure the build agent
  • Task 9: Create a Build Pipeline
  • Task 10: Create a Release Pipeline
  • Task 11: Run the full Continuous Integration and Continuous Deployment pipeline
  • Task 12: Optional additional configuration on release pipeline

Estimated Lab Time:

  • approx. 120 minutes

Additional Info:

A demo which is part of the course covers a similar, although not identical, scenario. You can view that demo video in the course in Module 1: Containerization > Lesson 7: Continuous Delivery Pipeline and Containers > Demo: Create CD Pipeline Using Containers and VSTS.

Lab files are also required for some lab task and they are available at https://github.com/Microsoft/PartsUnlimited/tree/master/Labfiles/Devops200.4x-ConfigMgmtForContainerizedDelivery/M01/Labs/

Task 1 : Deploy a virtual machine to Azure to use as an Azure DevOps build agent

It is possible, and sometimes preferable and easier to use one of the hosted agents available in Azure DevOps, when building your application, however we will be deploying a container to the build agent to allow us to perform a smoke test and as such, we will configure a dedicated machine. We will use an Azure virtual machine to do this. It is possible to also use your local environment, if you have a Windows 10 machine, and the steps related to build agent configuration are equally applicable to that.

In general, building on a local machine and verifying your work when checking in files before, committing to a master branch can be very useful and efficient.

Also, when building containers another factor to take into account when a container pipeline is run is if a new hosted build agent is used each time the container images need to be downloaded each time onto that build agent, and that will increase your build time. Using a local build agent or a dedicated virtual machine in Azure that you can spin up and down as you need, would mean if the images are already present on the build agent, they would not need to be downloaded again, thus reducing the build time.

  1. To deploy a virtual machine to Azure to use as our Azure Devops build agent click on the Deploy to Azure button below

  2. Fill in the details as required and outlined below and deploy the virtual machine by clicking Purchase.

    Note: The deployment script deploys a Windows Server 2016 Datacenter image with containers. It also installs some required flies such as Docker-for-windows and visual studio community edition 2017, and some visual studio workloads. It can take up to 60 mins to deploy. While the virtual machine is continue to the next Task, completing Tasks 2 to 7, returning then to this task to complete it.

    • Resource Group = specify a new resource group name
    • Location = choose an Azure datacenter location near you
    • Admin Username = use the default value of azureuser
    • Admin Password = enter a password value
    • Dns Label Prefix = enter some unique dns name for the build agent VM i.e. azdevgentek01
    • Windows OS version = leave the default value 2016-Datacenter-with-containers
    • Location = leave the default value [resourceGroup().location] which ensure all resources are placed in the same new resource group you specified earlier

  3. When the deployment is complete, go to the newly created resource group, and then the virtual machine and obtain the dns name of the virtual machine.

  4. On your local machine open Remote Desktop Connection and paste in the dns label of the virtual machine into the Computer box and click connect.

  5. Enable sharing of a local drive in rdp session to allow you copy and paste some details you will need during the configuration of the agent by clicking show options in the remote desktop connection dialogue, then going to the Local Resources tab and clicking on More…

  6. Under Local devices and resources select your local C drive.

  7. In the Windows Security - Enter your credentials dialogue click More Choices and select Use a different account then enter the username and password you used earlier when deploying the build agent virtual machine and click OK i.e.

    • User Name = azureuser
    • Password = < password value you specified earlier >

  8. Accept the certificate prompt by clicking Yes

  9. Once logged into the virtual machine, allow it to start and then open a command prompt as administrator, and run the below docker command just to verify docker is installed and available

     docker
    

Task 2: Create a new Azure DevOps Project

  1. You will need an Azure DevOps project, if you do not have one thsat you cna use created a new project in Azure DevOps and name it Cntr1Proj or something like that, accepting the default values for Version control and Work item process.

Task 3: Create Git repo and Import PartsUnlimited git repo

  1. In your new project clock on Repos > Files Click on Import and then import the PartsUnlimted git repo https://github.com/microsoft/partsunlimited

  2. In your project Repo > Files Note the URL of your repo by clicking on Clone and then copying the URL value. On your local C drive create a folder named configdetails, or something like that, and within it .txt file of the same name, and paste the value into a text file in a folder on your C drive. It will be required later.

Task 4 : Create a Personal Access Token (PAT)

  1. In your Azure DevOps project click on your profile icon in the top right hand corner and select Security

  2. Under Personal Access Tokens, click + New Token

  3. In the Create a new personal access token pane, enter the values required and click Create.

    • Name = enter a name
    • Organization = accept the defaults, should be your organization
    • Expiration = accept the defaults
    • Scopes = Full access

  4. In the Success! pane copy the token value and take a note of it. Paste it into notepad on your local C: drive, i.e. the same txt file you placed your project repo url details, so you have it easily, as it will be required later in the lab. We will configure an rdp connection later to share the local C drive and allow us copy and paste this value into a build agent VM. You will not be able to access the token value again. If you do not have the token when needed you will need to create a new one. We will configure our connection later to share the local C drive

Task 5. Create a Service Connection in Azure DevOps

You will also require a service connection in your Azure DevOps project to allow you connect to Azure when running your build and release pipelines.

If you do not have a service connection configured in your Azure Devops project you can follow the steps in Task 3: Setting up Service Connection in VSTS in the lab CI and CD with Azure DevOps - Quickstart to create one.

Task 6. Add Docker support to the application using Visual Studio 2017

Note: It is not essential to use Visual Studio to add docker support to your application, you can manually create the Docker files that you require and include them with your application. They are also made available in the labfiles in our PartsUnlimited application repo at https://github.com/Microsoft/PartsUnlimited/tree/master/Labfiles/Devops200.4x-ConfigMgmtForContainerizedDelivery/M01/Labs. However we will use Visual Studio in this instance to demonstrate how to use the capability in Visual Studio.

  1. On your local machine install Visual Studio 2017. If you do not have Visual Studio 2017 installed you can use the Community edition, available on http://www.visualstudio.com

  2. On your local machine create a local folder to place your Azure DevOps repo files i.e. C:\Repos\Cntr1proj

  3. On your local machine, open Visual Studio 2017 and go to Team Explorer then click on Manage connections icon and under local it repositories select Clone and enter the URL of your Azure DevOps repo, which you noted earlier, and enter the path to the local folder you created earlier, then click Clone.

  4. Open the PartsUnlimited solution in Visual studio, you can do so, by opening Solution Explorer and double clicking on PartsUnlimited.sln. It may take a few minutes as dependencies will be installed, indicated by an yellow warning sign over some folder i.e. under the PartsUnlimitedWebsite\Dependencies folder, wait until that has finished, i.e. when the yellow warning sign is no longer present.

    Note: You do not need to a manual build of the application prior to adding Docker support. If you do build the application you may encounter some errors which you’ll need to then address. You can see details about addressing potential errors and getting the application to successfully build in Visual Studio in the lab PartsUnlimited Setup with Visual Studio.

  5. Open a command prompt at your repo location and go to the folder src\PartsUnlimitedWebsite and run the command. This is just to reduce the risk of receiving errors if you build the PartsUnlimited application.

     npm rebuild node-sass
    

  6. In Solution Explorer right click PartsUnlimitedWebsite and select Add > Docker Support, and then chose Windows as the Target OS in the Docker Support Options prompt. This creates several docker container files and kicks off a build specifically using those container files.

  7. Several files are created in your solution, listed below. Open and browse through them to try understand what they are doing. These are the files we will use in our build and release pipeline, with a small bit of editing first.

    • docker-compose
      • dockerignore
      • docker-compose.yml
      • docker-compose.override.yml
    • PartsUnlimitedWebsite
      • Dockerfile

  8. Open the file PartsUnlimitedWebsite\Dockerfile and make the following changes.

    modify line 1 to read as below. We need to use a particular version, as it will run on our build agent which is WS2016 Datacenter with containers, and later versions will not run on this host. See here for windows container compatabililty considerations for more specific details.

     FROM microsoft/aspnetcore:2.0-nanoserver-sac2016 AS base
    

    modify line 5 to read as below. This is because we will build our application within the container and we require a non nano-server container image to successfully build our application.

     FROM microsoft/aspnetcore-build:2.0 AS build
    

    Add the following command at line 16. This is to overcome a dependency issue in our application and ensure a successful build.

     RUN npm rebuild node-sass
    

    After you make the changes the Dockerfile should look as below. There are two containers used in the file, the base is the container which we will run our final application, and the buld container is the container in which we will build the application, the output for that build is then copied into the base container as final.

  9. Save the file, then push the changes to your Azure Devops repo by clicking the Manage Connections icon, double clicking your repo, cntr1proj, under Local Git Repositories and clicking Changes.

  10. Then enter some text in the text box i.,e. updated dockerfile, and click Commit All for your listed changes, to commit them changes you made to the Dockerfile to your local repo.

    Note: You could also use git from the command line if you have it installed.

  11. Click the Manage Connections icon again, double clicking your repo, cntr1proj, under Local Git Repositories, click Sync and then under Outgoing Commits click Push to push the changes to you Azure DevOps project repo. You should then see a message confirming the successful push to the git repo origin/master.

  12. In your Azure DevOps repo you should now have the docker files present, as in the screenshot.

    You now have the files you need in your Azure DevOps repo to create a build pipeline for PartsUnlimited to be built into a container which we can then deploy.

Task 7. Create Azure Container Registry

This lab requires an Azure Container Registry. If you do not have one set up see Task 4 in the lab Working with Containers to create one.

Task 8: Install and configure the build agent

We now need to download and configure the agent on the build agent.

We earlier deployed a Windows Server 2016 with containers image as a virtual machine in Azure to use a build agent for demonstration purposes. As a result, we need to perform some additional steps to allow us configure our virtual machine as a build agent.

It is also possible to automate the agent configuration, and if you look at the Azure Quick Start Templates on github, there are examples of deployment templates for vsts build agents. We do it manually here to provide more context for what is happening for better understanding, even though it is more time consuming.

Also, if you copied the details you noted earlier for az devops account, PAT etc and stored them on your C: drive and then made that accessible in the rdp app, as outlined in the lab steps earlier, the values used in this Task should now be readily available from within that text file, inside the VM, by opening File Explorer under This PC as a mapped volume.

Finally, if you have any problems with your virtual machine with some of the steps below, try restarting the virtual machine to ensure all services are running as expected.

  1. Signed into your build agent, if you are using the azure virtual machine deployed earlier, open Server Manager, select Local server and then under IE Enhanced Security Configuration. click On

    Note: You would not normally do this on a server deployment, this is done purely for training purposes to allow us to perform some tasks and gain some learning from them.

  2. In the Internet Explorer Enhanced Security Configuration dialogue choose Off for both Administrators and users and click OK

  3. Access your Azure DevOps account from within the build agent, i.e. the azure virtual machine. You can do this in Internet Explorer, which is available on the server. This just makes it easier to install and configure the build agent on the build agent directly.

    Note: You may get prompted to add visualstudio.com and some other sites to trusted sites in the virtual machine, you can add these as you sign in, to prevent them appearing if you log in again later if you wish.

  4. In your Azure DevOps project, go to project settings and then Pipelines choose Agent pools and then select Download agent

  5. In the Get agent pane, click Download and save the agent to the default location. Leave the Get agent pane open, as you will copy the commands you need to run from here.

  6. Open PowerShell as an administrator and go to the root of the drive using the below command.

     cd\
    

  7. Return to the Get agent window, copy the first line in the commands listed, as below, paste it into PowerShell and run it i.e.

     Mkdir agent ; cd agent
    

    This just creates a folder C:\agent and enters that folder

  8. Return to the Get agent window, copy the second line in the commands listed, as below, paste it into PowerShell and run it. It should look something like the below,

     Add-Type -AssemblyName System.IO.Compression.FileSystem ; [System.IO.Compression.ZipFile]::ExtractToDirectory("$HOME\Downloads\vsts-agent-win-x86-2.141.1.zip", "$PWD")
    

    Note: Ensure you copy the command from the window and not this document, as the file version will change over time and the get agent dialogue command will have the latest version.`

  9. Open a command prompt window as administrator, go to the folder C:\Agent and run the command

     .\config.cmd
    

  10. Enter the below values when prompted

    Note: You will be prompted to enter the PAT that you created earlier, if you saved the PAT value in a txt file to your local C: drive, and you modified your rdp file to share the local drive, the values in that txt file should be available to copy and paste into the virtual machine now. The C drive will be present in File Explorer under This PC. If you have not and the drive is not available, you could disconnect your rdp session, re-configure the rdp session to share a local drive and place the data you need into a text file so it is available to copy into the command prompt when you need below. See steps earlier when connecting vis rdp for details on how to do this. You can also place other details required below into this file for use if needed.

    • Connect:
      • Enter server URL: https://< yourAzureDevOpsaccountname >.visualstudio.com
      • Enter authentication type (press enter for PAT): < press Enter >
      • Enter personal access token: < Paste the value you obtained in the Create a Personal Access token section earlier i.e. it should look something like 4avrb33twjq3f5wlqbkx7jzimmzt6h7ktyybbdojtu32x7yd3t2q >
    • Register Agent:
      • Enter agent pool (press enter for default): < Accept default by pressing Enter >
      • Enter agent name (press enter for < your machine name >): < Accept default by pressing Enter >
      • Enter work folder (press enter for _work) >< Accept default by pressing Enter >
      • Enter run agent as service? (Y/N) (press enter for N) > < enter Y >
      • Enter User account to use for the service (press enter for NT AUTHORITY\NETWORK SERVICE): < Enter the value NT Authority\SYSTEM >

      Note: If you use the default account, i.e. the NT Authority\Network Service account, it will not have sufficient Log on as Service permissions to successfully complete the Azure DevOps build tasks and you will receive an error when you go to build. You could also modify the service account settings for VSTS Agent in the Services.msc, and modifying the Log on as a Service setting there.

      You should receive several successful messages as it installs and configures the agent settings.

  11. In Azure DevOps project, go to Project settings > Pipelines > Agent pools again and then under All agent pools select the Default and verify your machine is listed and has a State of Online. If you have more than one build agent listed, uncheck the other agents, and leave this new agent checked to ensure the build gets run on it.

  12. Open a command prompt window as administrator and run the below command just to view what packages were installed using chocolatey during deployment. This is the package manager we used during deployment to install some additional software.

    choco list -localonly
    

  13. Restart your virtual machine and log in to ensure all services are running as expected. Your build agent is now ready and available.

    Note: Its a good idea to run some docker commands such as docker, docker ps and docker-compose, and make sure they perform as expected. If they do not, you will need to get them working by stepping back through the details in the earlier steps, otherwise you may receive build errors when you go to build your application on the agent.

Task 9: Create a Build Pipeline

As releases and updates occur frequently in Azure DevOps, there may be some differences in the steps below and what appears in the Azure Devops environment. Where discrepancies occur you should try to adhere to the main configuration points below and accept the default values where possible.

You do not need to perform these steps in the azure virtual machine build agent, they can be performed on your local machine if you wish.

  1. In your Azure Devops project go to Pipelines > Builds and then select New Pipeline.

  2. Under Select a source accept the defaults and click Continue

  3. Under Select a template scroll down until and select ASP.NET with containers. This will just pre-populate the build pipeline with a series of tasks which we can then edit.

  4. Under Tasks > Pipeline, In the Default agent queue drop down choose Default

    • Name: change the build pipeline name to something like PUcntrs1
    • Agent Pool: Default (This will lead us to use the build agent virtual machine we deployed to Azure earlier. We could use the Hosted Windows Containers option, and it can be a quick an easy option to use if you need, but we wish to do additional configuration on the build agent and using our own customised agent will give us some permanence and allow us to do this. You can see a list of the configurations on the page https://www.visualstudio.com/en-us/docs/build/concepts/agents/hosted
    • Solution: PartsUnlimited.sln < Use the ellipsis button beside the box to point to the PartsUnlimited.sln file at the root of our repo.>
    • Docker Compose File: docker-compose.yml < Use the ellipsis button beside the box to point to the docker-compose.yml file at the root of our repo. >
    • Azure Subscription: < The Azure service connection you created earlier, it should be available in the drop down box. If not you will need to create a service connection as per earlier steps. >
    • Azure Container Registry: < The azure container registry you created you created earlier. Again if none is listed ensure you’re service connection and azure container registry are created and available as in the steps earlier in the lab. >

  5. Under Tasks > Get Sources accept the default values.

  6. Accept the default values for Agent job 1 and also for the tasks Use NuGet 4.4.1 and NuGet restore

  7. Right click on the task Build solution PartsUnlimited.sln and from the context menu choose X Remove selected tasks(s). We will build the app inside a container which is being called within the dockerfile, so we do not need to build the app on the agent itself.

  8. Configure the Build services task using the below settings. If a setting is not mentioned below leave the default settings.

    • Display name: Build an image
    • Container Registry Type: Azure Container Registry
    • Azure Subscription: < choose your azure subscription, should be pre-populated from earlier. >
    • Azure Container registry: < your Azure Container service, should be pre-populated from earlier. >
    • Docker compose Files: < your docker-compose file in your repo root, should be pre-populated from earlier >
    • Additional Docker Compose Files: docker-compose.override.yml (this is the docker-compose.override.yml file that is in the root of your repo)
    • Action: Build service images
    • Include Latest Tag: check the box

  9. Configure the Push services task using the below settings. If a setting is not mentioned below leave the default settings.

    • Display name: Push an image
    • Container Registry Type: Azure Container Registry
    • Azure Subscription: < default as before >
    • Azure Container registry: < default as before >
    • Docker compose Files: < default as before >
    • Additional Docker Compose Files: docker-compose.override.yml (as before)
    • Action: Push service images
    • Include Latest Tag: check the box

  10. Configure the Lock services task using the below settings. If a setting is not mentioned below leave the default settings.

    • Display name: Lock services
    • Container Registry Type: Azure Container Registry
    • Azure Subscription: < default as before >
    • Azure Container registry: < default as before >
    • Docker compose Files: < default as before >
    • Additional Docker Compose Files: docker-compose.override.yml (as before)
    • Action: Lock service images

  11. Configure the Copy Files to: $(Build.ArtifactStagingDirectory) task using the below settings. If a setting is not mentioned below leave the default settings.

    • Source Folder: Labfiles/Devops200.4x-ConfigMgmtForContainerizedDelivery/M01/Labs < i.e. point to the labfiles for this lab in the repo at this location. >
    • Contents: ` *** ` (without no space between the wild characters and the forward slash. We wish to copy all files in the root folder and all files in all sub-folder. See the Copy Files task page for more details on how to specify the value.).
    • Target Folder: $(Build.ArtifactStagingDirectory)

  12. Accept the default values in the Publish Artifact: docker-compose task.

  13. Click on Triggers and choose Enable continuous integration. This will trigger a CI build when any change in the repo branch occurs, then save the build pipeline.

  14. To simulate a code check-in, to trigger the continuous integration build, trigger the build by going to your repo at\src\PartsUnlimitedwebsite\Controllers\HomeControllers.cs and clicking Edit to edit the file by add a comment to line 11 as below, and clicking Commit when finished

    //CI trigger text
    

    Note: You could also just click the queue build option, but this method is simulating a CI build based on code check-in.

  15. Return to the build pipelines and open the build to view the build progress output in the build Console. For a first build run it could take up to 30 minutes to complete, as container images need to be downloaded to the build agent. For subsequent runs it can take approx 10 minutes to complete as images are already present on the build agent.

  16. Verify the build runs successfully for both the build an image and push an image tasks.

    Note: You may receive errors on your first few runs as you iron out configuration issues. This is normal. You should view the build progress as it runs and identify any errors, and iterate your build definition, each time triggering a new build to test your pipeline. You can view each build in the build summary page. It may take several runs to get the build and push working successfully.

    If you see warnings regarding the Lock service, it is fine to ignore these as it will not affect your build.

  17. Go to you Azure Container registry and verify the container image is present from the build that was just run. You can click down into the repo and see various image versions present after multiple runs of the build. The container image has been tagged with the version number and there is also a tag for latest, the latest version number and the latest tag are the same container image.

  18. Finally, in you Azure DevOps project repo, go to the file Labfiles/Devops200.4x-ConfigMgmtForContainerizedDelivery/M01/Labs/releasepipelinecomposefile/docker-compose.yml and edit the name of the Azure Container registry to your own Azure Container registry, where your image wil be stored, and commit the change. It is important you make this change to the container registry in this file, otherwise you may encountered failed deployments. This will kick of a continuous integration build and we will use the resulting artifact in our release pipeline.

Task 10: Create a Release Pipeline

Now we will create a release pipeline to deploy our newly built application

  1. In your Azure DevOps project go to Pipelines > Releases > and click on NewPipeline

  2. In the Select a template pane select empty job

  3. In the Stage pane for Stage name enter Smoke Test and then close the dialogue by clicking the X in the top right corner

  4. In the pipeline under Artifacts click Add an Artifact choose the project and build definition you created earlier, then for Source Alias enter the value Artifacts and click Add

  5. Go to Tasks > Smoke Test and under Agent job > Agent pool select Default, to indicate that you want to run the commands on the agent you created and used earlier for your build pipeline.

  6. On Agent job click the + sign and in the Add tasks > Build select Docker Compose and click Add to add two instances of the task to your pipeline.

  7. Still in Add tasks under Deploy select Azure PowerShell and click Add to add the task to your pipeline.

  8. Re-order the added tasks in your pipeline so the powershell task is second, between the two docker compose tasks.

  9. Configure the first Docker task with the following details, where a field is not listed leave the default value. This task will run the container.

    • Display name: Run Services
    • Container Registry Type: Azure Container Registry
    • Azure Subscription: < Your Azure Subscription >
    • Azure Container Registry: < the name of your Azure Container Registry >
    • Docker-compose File: < click the ellipsis button at the end of the box and in the artifacts window point to the build artifact docker-compose/releasepipelinecomposefile/docker-compose.yml. This is a different docker compose file to that generated by visual studio earlier. It is one we created ourselves, specifically to run the image as we want on our build agent. >
    • Action: Run service Images
    • Build Images: Uncheck the checkbox
    • Run in background: Check the checkbox

  10. Configure the second, or Azure PowerShell script task, as per the below, again where a field is not listed leave the default value. This task will programmatically check if the container is running successfully.

    • Display name: Azure PowerShell script: FilePath
    • Azure Connection Type: Azure Resource Manager
    • Azure Subscription: < Your Azure Subscription >
    • Script Type: Script File path
    • Script Path: < click the ellipsis button at the end of the box and in the artifacts point to Artifact/docker-compose/dockercontainerruncheck.ps1 >
    • Azure Powershell Version: Latest installed version

  11. Configure the third, the last Docker task as per the below, again where a field is not listed leave the default value. This task will stop the running container.

    • Display name: Run a Docker Compose command
    • Container Registry Type: Azure Container Registry
    • Azure Subscription: < Your Azure Subscription >
    • Azure Container Registry: < the name of your Azure Container Registry >
    • Docker-compose Files: < click the ellipsis button at the end of the box and in the artifacts window point to the build artifact docker-compose/releasepipelinecomposefile/docker-compose.yml. >
    • Action: Run a docker compose command
    • Command: down

  12. Go to the Pipeline and within Artifacts, click on the continuous deployment trigger icon and enable Continuous Deployment.

  13. Save the Release pipeline, by clicking Save.

  14. Click on + Release > + Create a Release and in the create new release dialogue select the latst artifact version and then click Create. This will run just the release pipeline, and not the previously defined build definition, to verify your configuration

  15. If it completes successfully, It should deploy the partsunlimitedwebsite container image to the build agent, the azure virtual machine you deployed earlier. All tasks in the release pipeline should complete successfully, and take only one to two minutes maximum.

    If the Powershell task completes successfully, that means the container info was obtained successfully by the powershell script i.e. the website was up and running successfully. You can view the Logs tab content in the Azure DevOps release pipeline, it will contain all the command line output and details from the deployment. The output of the Powershell task in the logs should also contain Statuscode: 200 and status description: OK and some html and other details which the script has taken from the running website to verify it has deployed successfully. If the website in the container was not running successfully, it would not return this data.

    If the powershell script fails, it may be because the container was not running properly, even if the previous docker task shows as successful, it would be worth verifying.

    Another option to verify the deployment is to disable the last docker task in the release pipeline, which stops the container, and run a new release, then obtaining the public IP address of you build agent virtual machine, and going to that ip address and port 8080, i.e. http://:8080, as the host port on the agent of 8080,. is mapped to the container port 80. The PartsUnlimited web site should display successfully in a browser. You can also get the IP address using Docker Inspect < container ID > and opening a browser, to verify the page displays successfully. You can verify that by viewing the **docker ps -a** command output on the build agent, and verifying the container was up and running.

    Also, when editing the release pipeline, be sure you are editing the actual release pipeline and not a past pipeline that has already been run, i.e. which have the default label of Release-1, -2, -3, 4 etc. If you edit these releases, and save the changes, that will not affect the general definition. Right click on the release pipelines as defined under Release pipelines pane, and choose edit, then Save your changes here. Otherwise, you may think you are editing the release definition but are actually editing a previous run of the definition.

  16. If you have time you could run the release a couple of times with the above variations, and verify it runs successfully, each time checking the Logs, and various configuration options.

Task 11: Run the full Continuous Integration and Continuous Deployment pipeline

We will now run the build and release pipelines.

  1. To simulate a code check-in, to trigger the continuous integration build, trigger the build by going to your repo and click Edit editing the \src\PartsUnlimitedwebsite\Controllers\HomeControllers.cs by add a comment to line 11 as below, and clicking Commit when finished

     //CI trigger text
    

  1. Return to the build pipelines and open the build, to view the command line build progress output in the build Console.

  2. Once the build is complete, the release should start automatically.

  3. View the release progress by viewing the Logs to verify successful deployment.

  4. Verify the container has been deployed successfully to your build agent and open the agent public name or IPAddress in a web browser and the host port number of 8080, and verify the container is visible on the web page.

    Note: As stated earlier, you may receive errors on your first few runs as you iron out configuration issues. This is normal. You should view the build progress as it runs and identify any errors, and iterate your build definition, each time modifying your Azure DevOps repository file to trigger a new build. You can view each build in the build summary page. It may take several runs to get the build and push working successfully.

Task 12: Optional additional configuration on release pipeline

When deploying to a test environment, which we are simulating here, you would typically deploy the application, then perform some tests, built into your release definition, then perform some clean up tasks, to leave a clean deployment environment for the next deployment. We will not include tests in this release definition, as it would add to complexity and time requirement and is a whole topic on its own, we could also add additional release tasks

  • We could add a task here to Remove an Image, and enable the task by checking the Enabled checkbox.
  • We could deploy to Azure Container Instance or Azure Web Apps for Containers services in Azure.
  • Add some tasks performing some other tests on the deployed container and image
  • You could also add additional release environments for Staging, Production etc, each time adding additional tasks required for that stage, such as unit tests, verification tests etc.
  • You can also build in additional configuration options around approvals before deploying to production as well as many other options. You should click around and modify your settings to try different scenarios and configuration options as you have time.

Summary

In this lab you completed the following tasks:

  • Deployed a virtual machine to Azure to use as an Azure DevOps build agent
  • Created a new Azure DevOps Project
  • Created Git repo and Import PartsUnlimited git repo
  • Created a Personal Access Token (PAT)
  • Created a Service Connection in Azure DevOps
  • Added Docker support to the application using Visual Studio 2017
  • Created Azure Container Registry
  • Install and configure the build agent
  • Created a Build Pipeline
  • Created a Release Pipeline
  • Ran the full Continuous Integration and Continuous Deployment pipeline
  • Performed some optional additional configuration on release pipeline