azuredevopslabs/labs/azuredevops/yaml at master · oncloudtraining/azuredevopslabs

Name	Name	Last commit message	Last commit date
parent directory ..
images	images
readme.md	readme.md

title	layout	sidebar	permalink	folder	version	updated
Configuring CI/CD Pipelines as Code with YAML in Azure DevOps	page	vsts	/labs/azuredevops/yaml/	/labs/azuredevops/yaml/	Lab version - 1.37.1	Last updated - 9/5/2019

Overview

Many teams prefer to define their build and release pipelines using YAML (Yet Another Markup Language). This allows them to access the same pipeline features as those using the visual designer, but with a markup file that can be managed like any other source file. YAML build definitions can be added to a project by simply adding their source file to the root of the repository. Azure DevOps also provides default templates for popular project types, as well as a YAML designer to simplify the process of defining build and release tasks.

Prerequisites

This lab requires you to complete task 1 from the prerequisite instructions.

The following image will walk you through all the steps explained in this lab

Exercise 1: Configuring CI/CD Pipelines as Code with YAML in Azure DevOps

Task 1: Creating Azure resources

This lab requires a deployment of the Parts Unlimited project out to an Azure app service. To do this, you will need to spin up the necessary infrastructure. Log in to your Azure account at https://portal.azure.com.
Click Create a resource and search for "web sql".
Select the Web App + SQL option published by Microsoft.
Click Create.
Enter a globally unique name for the app service. You may find it easiest to incorporate your name, such as "pul-yaml-johndoe". Select the option to create a new resource group named "partsunlimited".
Select the option to configure the SQL Database. Click Create a new database and enter the name "partsunlimited".
Select the option to configure the Target server and click Create a new server. Enter a globally unique server name, such as "pul-yaml-johndoe" and provide admin credentials. Click Select to confirm the server settings.
Click Select to confirm the database settings.
Click Create to create the resources. Note that you may need to create an app service plan first, if you do not yet have one.
It will take a few minutes for the resources to provision, so you can move on to the next task.

Task 2: Configuring the Parts Unlimited project

Navigate to your team project on Azure DevOps in a new browser tab. Before digging into the YAML pipelines, you will want to disable the existing build pipeline.
Navigate to Pipelines.
Select the existing PartsUnlimitedE2E pipeline.
From the dropdown, select Pause pipeline.

Task 3: Adding a YAML build definition

Navigate to the Pipelines hub.
Click New pipeline. We will use the wizard to automatically create the YAML definition based on our project.
Select the Azure Repos Git as the source hosting platform. Note the others supported.
Select the PartsUnlimited repo.
Select the ASP.NET template as the starting point for your pipeline.
Review the contents of the YAML definition. It will be saved as a new file called "azure-pipelines.yml" in the root of the repository and contain everything needed to build and test a typical ASP.NET solution. You can also customize the build as needed. In this case, update the pool to specify the build should use a Visual Studio 2017 build VM. Be sure to keep it at the same two-space indentation.
```
name: Hosted VS2017
demands:
- msbuild
- visualstudio
- vstest
```
Click Save and run.
Click Save and run to confirm the commit.
Track the build until it completes. Click Job to see the logs.
Each task from the YAML file is available for review, including any warnings and errors.
Close the tasks view.
Select the Tests tab.
The tests should now succeed as expected.

Task 4: Adding continuous delivery to the YAML definition

Now that the build and test processes are successful, we can now add delivery to the YAML definition. From the options dropdown, select Edit pipeline.
Add the configuration lines below after the trigger section to define a Build stage in the YAML pipeline. You can define whatever stages you need to better organize and track pipeline progress.
```
stages:
- stage: Build
  jobs:
  - job: Build
```
Highlight the remainder of the YAML file and indent it four spaces (two tabs). This will simply take the existing build definition and relocate it as a child of the jobs node.

At the bottom of the file, add the configuration below to define a second stage.

- stage: Deploy
  jobs:
  - job: Deploy
    pool:
      name: Hosted VS2017
    steps:

Set the cursor on a new line at the end of the YAML definition. This will be the location where new tasks are added.
Select the Azure App Service Deploy task.
Select the Azure subscription where you created the app service earlier. Click Authorize and follow the path to complete authorization.
Enter the App Service name you used to create the app service earlier. Update the Package or folder to "$(System.ArtifactsDirectory)/drop/*.zip". Click Add.
The YAML that defines the task will be added to the cursor location in the file.
With the added task still selected in the editor, indent it four spaces (two tabs) so that it is a child of the steps task.
It's important to note that these two stages will be run independently. As a result, the build output from the first stage will not be available to the second stage without special consideration. For this, we will use one task to publish the build output at the end of the build stage and another to download it in the beginning of the deploy stage. Place the cursor on a blank line at the end of the build stage.
Search the tasks for "publish build" and select the Publish Build Artifacts task. There may be more than one available, so be sure to select the one that is not deprecated.
Accept the defaults and click Add. This will publish the build artifacts to a location that will be downloadable under the alias drop.
Indent the publish task four spaces (two tabs). You may also want to add an empty line before and after to make it easier to read.
Place the cursor on the first line under the steps node of the deployment stage.
Search the tasks for "download build" and select the Download Build Artifacts task.
Click Add.
Indent the publish task four spaces (two tabs). You may also want to add an empty line before and after to make it easier to read.
Add a property to the download task specifying the artifactName of "drop". Be sure to match the spacing.
```
artifactName: 'drop'
```
Click Save to commit the changes.
Confirm the Save. This will begin a new build.
Return to the Pipelines view.
From the Runs tab, click the new build run to open it. Note that there are now multiple stages shown based on the YAML definition edits from earlier.
If you see an error message requiring you do Authorize resources, click the button to do so. Then click Run new from the top right corner and follow the process to queue a new build.
When the Build stage completes, click the Deploy stage to follow each task.
Expand the AzureRmWebAppDeployment task to review the steps performed during the Azure deployment. Once the task completes, your app will be live on Azure.

Task 5: Reviewing the deployed site

Return to the Azure portal browser tab.
Navigate to the app service created earlier.
Select the Configuration tab.
Click the defaultConnection setting.
Update the Name to "DefaultConnectionString", which is the key expected by the application. This will enable it to connect to the database created for the app service. Click OK.
Click Save to apply the changes.
Return to the Overview tab.
Click Browse to open your site in a new tab.
The deployed site should load expected.