Azure Notes

Azure pipeline key terms

Agent – installable software that runs a build or deployment

Artifact – collection of files published by a build

Build – one execution of a build pipeline

Deployment target – Any service that will host an app

Job – an execution boundary of a set of steps

Pipeline
Accessing Microsoft Azure
Launch Chrome from the virtual machine desktop and navigate to the URL below. Your
Azure Credentials are available by clicking the Cloud Icon at the top of the Lab Player.

zoom code

copy code
https://portal.azure.com

Exercise 2: Preparing the Azure DevOps Lab Environment

Certain Azure DevOps labs require a pre-configured Parts Unlimited team project. This
document outlines the required steps to set up the required data.

Task 1: Configuring the Parts Unlimited team project

1. Open the Chrome browser and navigate to the link below to begin provisioning a
new Azure DevOps instance for your lab.

zoom code

copy code

https://dev.azure.com
2. Click the Start free button and then enter the credentials made available by
clicking on the Cloud Icon at the top of the Lab Player.

3. You’ll be prompted to enter some basic information to complete the provisioning

of the Azure DevOps account. Click Continue and then stop when you are asked
to Create a project to get started.

4. In the same Chrome browser tab, navigate to the link below. This utility site will
automate the process of creating a new project within your newly created Azure
DevOps account that is pre-populated with content (work items, repos, etc.)
required for this lab.

zoom code

copy code

https://azuredevopsdemogenerator.azurewebsites.net
5. Click Sign In and, if asked, use the same credentials made available by clicking on
the Cloud Icon at the top of the Lab Player.
 zoom image

6. If you are presented with a We need a few more details screen, feel free to
update the Your name field, but it’s not required. Click Continue.

7. Accept the permission requests for accessing your subscription.

zoom image
8. Select your Azure DevOps organization and enter the project name “Parts
Unlimited”. Click Choose Template.
 zoom image

9. Select the PartsUnlimited template and click Select Template.

zoom image

10. Click Create Project and wait for the process to complete. This can take a couple
minutes.

zoom image

11. After the process has completed. Click on the Navigate to project button to

navigate to the newly created project.

zoom image
Exercise 3: Configuring Visual Studio Code
In this exercise, you’ll configure a Git credential helper to securely store the Git
credentials to communicate with Azure DevOps.

Task 1: Configuring Visual Studio Code

1. Open Visual Studio Code.

2. From the main menu, select Terminal and then New Terminal to open a

terminal window.

3. Execute the command below to configure a credential helper.

zoom code

copy code

git config --global credential.helper wincred

4. The commands below will configure your username and email for Git commits.
Replace the parameters with your preferred user name and email and execute
them.

zoom code

copy code

git config --global user.name "John Doe"

zoom code

copy code

git config --globa. user.email johndoe@example.com

Exercise 4: Cloning an existing repository
In this exercise, you’ll clone an existing repository and install a new extension in Visual
Studio Code for working with Azure Repos.

Task 1: Cloning an existing repository

1. In a browser tab, navigate to your team project in Azure DevOps.

2. Getting a local copy of a Git repo is called “cloning”. Every mainstream

development tool supports this and will be able to connect to Azure Repos to
pull down the latest source code to work with. Navigate to the Repos hub.

zoom image

3. Click Clone.

zoom image

4. Click the Copy to clipboard button next to the repo clone URL. You can plug this
URL into any Git-compatible tool to get a copy of the codebase.

zoom image
5. Return to Visual Studio Code.

6. Press Ctrl+Shift+P to show the Command Palette. The Command Palette

provides an easy and convenient way to access a wide variety of tasks, including
those provided by third-party extensions.

7. Execute the Git: Clone command. It may help to type “Git” to bring it into the
shortlist.

zoom code

copy code

>Git: Clone

zoom image

8. Paste in the URL to your repo and press Enter.

zoom image

9. Navigate to C:\OpsgilityTraining and click Select Repository Location

 10. When prompted, log in to your Azure DevOps account using the lab provided
credentials in the cloud icon.

11. Once the cloning has completed, click Open in the bottom right corner. You can
ignore any warnings raised about opening the projects. The solution may not be
in a buildable state, but that’s okay since we’re going to focus on working with
Git and building the project itself.

zoom image

Task 2: Installing the Azure Repos extension for Visual Studio Code
1. The Azure Repos extension provides convenient access to many features of Azure
DeVOps. From the Extensions tab, search for “Azure Repos” and click Install to
install it.

zoom image

2. Click Reload once the extension has finished installing. If this option is not

available, reopen Visual Studio Code. Be sure to click Learn More in the bottom
right then close the browser window that pops up.

zoom image
3. Press Ctrl+Shift+P to show the Command Palette.

4. Search for “>Team” to see all the new commands that are now available for
working with Azure Repos. Select Team: Signin.

zoom image

5. Select Authenticate and get an access token automatically. Note that you

could alternatively provide the token created earlier if you were following a
manual path.

zoom image
 6. Copy the provided token and press Enter to launch a browser tab.

zoom image

7. Paste the code in to the login box and click Next.

zoom image

8. Select the lab account and sign in.

9. When the process has completed, close the browser tab.

Exercise 5: Saving work with commits

When you make changes to your files, Git will record the changes in the local repository.
You can select the changes that you want to commit by staging the changes. Commits
are always made against your local Git repository, so you don’t have to worry about the
commit being perfect or ready to share with others. You can make more commits as you
continue to work and push the changes to others when they are ready to be shared.

What’s in a commit?

Git commits consist of the following: - The file(s) changed in the commit. Git keeps the
contents of all file changes in your repo in the commits. This keeps it fast and allows for
intelligent merging. - A reference to the parent commit(s). Git manages your code
history using these references. - A message describing a commit. You give this message
to Git when you create the commit. It’s a good idea to keep this message descriptive,
but to the point.

Task 1: Committing changes

1. From the Explorer tab, open /PartsUnlimited-
aspnet45/src/PartsUnlimitedWebsite/Models/CartItem.cs.

zoom image

2. Add a comment to the file. It doesn’t really matter what the comment is since the
goal is to simply make a change. Press Ctrl+S to save the file.
 zoom image

3. Select the Source Control tab to see the one change to the solution.

zoom image

4. Enter a commit message of “My commit” and press Ctrl+Enter to commit it

locally.

zoom image

5. If asked whether you would like to automatically stage your changes and commit
them directly, click Always. We will cover staging later in the lab.

zoom image
 6. Click the Synchronize Changes button at the bottom left to sync your changes
with the server. Confirm the sync if prompted.

zoom image

Task 2: Reviewing commits

1. Switch to the Azure DevOps browser tab. You can review the latest commits in
Azure DevOps under the Commits tab of the Repos hub.

zoom image

2. The recent commit should be right at the top.

zoom image
Task 3: Staging changes
Staging changes allows you to selectively add certain files to a commit while passing
over the changes made in other files.

1. Return to Visual Studio Code.

2. Update the open CartItem.cs class by editing the comment you made earlier and
saving the file.

zoom image

3. Open Category.cs as well.

zoom image
4. Add a new comment to Category.cs so there will be two files with changes. Save
the files.

zoom image

5. From the Source Control tab, click the Stage Changes button for CartItem.cs.

zoom image

6. This will prepare CartItem.cs for committing without Category.cs.

zoom image

7. Enter a comment of “Added comments”. From the More Actions dropdown,

select Commit Staged.
 zoom image

8. Click the Synchronize Changes button to sync the committed changes with the

server. Note that since only the staged changes were committed, the other
changes are still pending locally. Be sure to confirm the sync when prompted.

zoom image

Exercise 6: Reviewing history

Git uses the parent reference information stored in each commit to manage a full history
of your development. you can easily review this commit history to find out when file
changes were made to determine differences between versions of your code using the
terminal or form one of the many Visual Studio Code extensions available. You can also
review changes using the Azure DevOps portal.

Git’s use of the Branches and Merges feature works through pull requests, so the
commit history of your development doesn’t necessarily form a string, chronological
line. When you use history to compare versions, think in terms of file changes between
two commits instead of file changes between two points in time. A recent change to a
file in the master branch may have come from a commit created two weeks ago in a
feature branch but was only merged yesterday.

Task 1: Comparing files

1. In the Source Code tab, select Category.cs.

zoom image

2. A comparison view is opened to enable you to easily locate the changes you’ve
made. In this case, it’s just the one comment.

zoom image

3. Press Ctrl+Shift+P to open the Command Palette.

4. Start typing “>Team” and select Team: View History when it becomes available.

This is a feature of the Azure Repos extension that makes it easy to jump right to
the history of this file in a new browser window.

zoom image
5. Note the history of Category.cs. Close the newly created window, and return to
the Commits tab from earlier. You may have to click Commits.

zoom image

6. Scroll down in the Commits view to locate some of the source branches and

merges. These provide a convenient way to visualize when and how changes
were made to the source code.

zoom image
7. From the dropdown for Merged PR 27, select Browse Files.

zoom image

8. This view offers the ability to navigate around the state of the source code at that
commit so you can review and download those files.

zoom image
Exercise 7: Working with branches
You can manage the work in your Azure DevOps Git repo from the Branches view on
the web. You can also customize the view to track the branches you care most about so
you can stay on top of changes made by your team.

Committing changes to a branch will not affect other branches and you can share
branches with others without having to merge the changes in to the main project. You
can also create new branches to isolate changes for a feature or a bug fix from your
master branch and other work.

Since the branches are lightweight, switching between branches is quick and easy. Git
does not create multiple copies of your source when working with branches, but rather
uses the history information stored in commits to recreate the files on a branch when
you start working on it. Your Git workflow should create and use branches for managing
features and bug fixes. The rest of the Git workflow, such as sharing code and reviewing
code with pull requests, all work through branches. Isolating work in branches makes it
very simple to change what you are working on by simply changing your current branch.

Task 1: Creating a new branch in your local repository

1. Return to Visual Studio Code.

2. Click the master branch from the bottom left.

zoom image

3. Select Create new branch from….

zoom image

4. Enter the name “dev” for the new branch and press Enter.
 zoom image

5. Select the master as the reference branch.

zoom image

6. You are now working on that branch.

zoom image

Task 2: Working with branches

Git keeps track of which branch you are working on and makes sure that when you
checkout a branch, your files match the most recent commit on that branch. Branches
let you work with multiple versions of the source code in the same local Git repository at
the same time. You can use Visual Studio Code to publish, checkout and delete
branches.

1. Click the Publish changes button next to the branch.

zoom image

2. From the Azure DevOps browser tab, select Branches.

zoom image
3. You should see the newly pushed dev branch. Click the Delete branch button to
delete it. Confirm the delete.

zoom image

4. Return to Visual Studio Code.

5. Click the dev branch.

zoom image

6. Note that there are two dev branches listed. The local (dev) branch is there
because it’s not deleted when the server branch is deleted. The server
 (origin/dev) is there because it hasn’t been pruned. Select the master branch to
check it out.

zoom image

7. Press Ctrl+Shift+P to open the Command Palette.

8. Start typing “>Git: Delete” and select Git: Delete Branch when it becomes

visible.

zoom image

9. There is only one local branch to delete, so select it.

zoom image

10. Click the master branch.

zoom image
11. Note that the local dev branch is gone, but the remote origin/dev is still
showing.

zoom image

12. Press Ctrl+Shift+P to open the Command Palette.

13. Start typing “>Git: Fetch” and select Git: Fetch (Prune) when it becomes visible.
This command will update the origin branches in teh local snapshot and delete
those that are no longer there.

zoom image

14. You can check in on exactly what these tasks are doing by selecting
the Output window at the bottom of the screen. You may have to click View >
Output in the top tool bar to see it.

zoom image
 15. Note that if you don’t see the Git logs in the output console, you may need to
select Git as the source.

zoom image

16. Click the master branch.

zoom image

17. The origin/dev branch should no longer be listed.

zoom image

Exercise 8: Managing branches from Azure DevOps

In addition to all the functionality available in Visual Studio Code, you can also manage
your repo branches from the Azure DevOps portal.

Task 1: Creating a new branch

1. Switch to the Azure DevOps browser tab.

2. Navigate to Repos, then Branches. Click New branch.

zoom image
3. Enter a name of “release” for the new branch. Use the Work items to
link dropdown to select one or more work items to link to this new branch.
Click Create branch to create it.

zoom image

4. After the branch has been created, it will be available on the list.

zoom image
 5. Return to Visual Studio Code.

6. Press Ctrl+Shift+P to open the Command Palette.

7. Start typing “>Git: Fetch” and select Git: Fetch when it becomes visible. This
command will update the origin branches in the local snapshot.

zoom image

8. Click the master branch.

zoom image

9. Select origin/release. This will create a new local branch called “release” and
check it out.

zoom image

Task 2: Deleting a branch

1. Return to Azure DevOps and click the Delete button that appears when you
hover over the release branch to delete it. Confirm the deletion.
 zoom image

2. However, maybe we should keep it around for a little longer. From its context
menu, select Restore branch.

zoom image

Task 3: Locking a branch

Locking is ideal for preventing new changes that might conflict with an important merge
or to place a branch into a read-only state. Alternatively, you can use branch policies
and pull requests instead of locking it you just want to ensure that changes in a branch
are reviewed before they are merged.

Locking does not prevent cloning of a repo or fetching updates made in the branch into
your local repo. If you local a branch, share with your team the reason why and make
sure they know what to do to work with the branch after it’s unlocked.

1. From the master context menu, select Lock.

zoom image
2. The branch is now locked.

zoom image

3. Now Unlock the branch using the same process.

zoom image
Task 4: Tagging a release
1. White it may not seem like much, the product team has decided this version of
the site is exactly what’s needed for v1.1. In order to mark it as such, navigate to
the Tags tab.

zoom image
2. Click Create Tag.

zoom image

3. Enter a Name of “v1.1” and a Description of “Great release!”. Then, click Create.

zoom image
 4. You have now tagged the project at this release. You could tag commits for a
variety of reasons and Azure DevOps offers the flexibility to edit and delete them,
as well as manage their permissions.

zoom image

Exercise 9: Managing repositories

You can create Git repos in team projects to manage your project’s source code. Each
Git repo has its own set of permissions and branches to isolate itself from other work in
your project.

Task 1: Creating a new repo from Azure DevOps

1. From the project Add dropdown, select New repository.

zoom image
2. Set the Repository name to “New Repo”. Note that you also have the option to
create a file named README.md. This would be the default markdown file that is
rendered when someone navigates to the repo root in a browser. Additionally,
you can pre-configure the repo with a .gitignore file. This file specifies which
files, based on naming patterns and/or path, it ignore from source control. There
are multiple templates available that include the common patterns and paths to
ignore based on the project type you are creating. Then, click Create.

zoom image

3. That’s it. Your repo is ready. You can now clone it with Visual Studio Code or your
tools of choice.

zoom image
Task 2: Deleting and renaming Git repos
1. Sometimes you’ll have a need to rename or delete a repo, which is just as easy.
Open Project settings on the bottom left.

zoom image

2. Select Repositories under Repos.

zoom image

3. From the New Repo context menu, select Delete repository. Alternatively, you

could rename it here.

zoom image

4. Enter the name “New Repo” to confirm the repo delete and click Delete.

zoom image
Summary
Congratulations! You have learned how to manage version control with Git using Visual
Studio Code and Azure DevOps.
Lab Guide
Configuring CI/CD Pipelines Pipelines as Code with YAML in Azure DevOps
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 and controlled 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 YAML templates for popular
project types, as well as a YAML designer which can simplify the process of defining
build and release tasks.

Learning Objectives

 Understand how to add a YAML build definition to an Azure DevOps Pipeline

 Understand how to add continuous delivery functionality to a YAML definition file

Accessing Microsoft Azure

Launch Chrome from the virtual machine desktop and navigate to the URL below. Your
Azure Credentials are available by clicking the Cloud icon at the top of the Lab Player.

zoom code

copy code
https://portal.azure.com
Exercise 1: Configure Team Project
In this exercise, you’ll set up an Azure DevOps project and populate it with the Parts
Unlimited demo project files for us to use as a starting point.

Task 1: Configuring the Parts Unlimited team project

1. Navigate to the Azure DevOps Demo Generator site to get started creating your
Azure DevOps organization.

zoom code

copy code

https://azuredevopsdemogenerator.azurewebsites.net/
 This utility site will automate the process of creating a new Azure DevOps project
within your lab account that is pre-populated with content (work items, repos,
etc.) required for the lab.

2. Create a new Azure DevOps organization by clicking the Get started for

free button. Then sign in with your lab subscription credentials (found by clicking
the cloud icon in the lab player) when prompted.

zoom image

Get Started for Free

Click Continue on the We need a few more details page. Then, on the next

screen click Create new organization.

zoom image
 Get Started for Free

3. Click Continue on the Get Started with Azure DevOps prompt to agree to the

terms of service. Then click Continue again to finish creating the DevOps
organization. You’ll be prompted to create a project on the next page, but you
don’t need to do so yet.

zoom image
 Get Started for Free

4. After your organization is created, navigate back to the Azure DevOps Demo
Generator using the url below and this time click Sign in.

zoom code

copy code

https://azuredevopsdemogenerator.azurewebsites.net/

zoom image
5. Click Accept at the prompt to grant the demo generator the necessary
permissions on your DevOps organization.

Then on the Create New Project page, select your Azure DevOps organization

from the dropdown menu and enter the project name “Parts Unlimited”. Finally,
click Choose Template.

zoom image

6. Select the PartsUnlimited template (not PartsUnlimited-YAML) from the list, then

click Select Template.

zoom image
7. Back on the Create New Project page, click Create Project. Your project will
begin creating, and a progress bar will appear below the Create Project button.

zoom image
Summary
In this exercise, you created an Azure DevOps organization, as well as generated the
sample project we will use for the rest of the lab’s exercises

———————————————————————–+ | Conditions and Terms of Use |

+========================================================
===============+ | The MIT License (MIT) | | | | Copyright (c) 2018 Microsoft
Corporation. All rights reserved. | | | | Permission is hereby granted, free of charge, to any
person obtaining | | a copy of this software and associated documentation files (the | |
"Software"), to deal in the Software without restriction, including | | without limitation
the rights to use, copy, modify, merge, publish, | | distribute, sublicense, and/or sell
copies of the Software, and to | | permit persons to whom the Software is furnished to
do so, subject to | | the following conditions: | | | | The above copyright notice and this
permission notice shall be | | included in all copies or substantial portions of the
Software. | | | | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, | | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
| | MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND | |
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS | |
BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN | | ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN | | CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE | | SOFTWARE. | +
———————————————————————–+

Exercise 2: Configuring CI/CD Pipelines as Code with YAML

In this exercise, you’ll configure a CI/CD pipeline as code with YAML, and trigger a build
and release of your project to Azure App Service.

Task 1: Creating Azure resources

1. Navigate to the Azure Portal and login with your lab credentials if prompted.

zoom code

copy code

https://portal.azure.com
2. Expand the navigation menu by clicking the Show portal menu button. Click +
Create a resource and search for then select “web app + sql”.

zoom image

zoom image

zoom image

3. Click Create.
 zoom image

4. Enter a globally unique name for the app service. Select the option to Use
existing resource group named “SkillMeUpRG”.

zoom image

5. Click SQL Database to configure the database settings, then enter the Name
“partsunlimited”. This is the database our application will expect to connect to.

zoom image
6. Select Target server and enter a globally unique server name, such as “pul-
yaml-johndoe” and provide the following admin credentials:

o Server admin login: demouser

o Password: demo@pass123
o Location: Choose a close/supported region

Click Select to confirm the server settings.

zoom image
7. Next, select Configure pricing tier and then click the link: Looking for Basic,
Standard, Premium?.

zoom image

8. Select Standard, then click Apply.

zoom image
9. Click Select to confirm the database settings.

zoom image

10. Finally, click Create to create the resources involved in our Web App + SQL
deployment.
 zoom image

Task 2: Setup Permissions to your Azure Subscription

Now we’ll grant your Azure DevOps project access to your Azure Subscription.

1. Navigate back to Azure DevOps in a new browser tab:

zoom code

copy code

https://dev.azure.com
2. Click your project then select Project Settings at the bottom left.

zoom image
3. In the left navigation under Pipelines, click Service Connections.

zoom image
4. Click Create Service Connection -> Azure Resource Manager -> Next.

zoom image
5. Click Service principal (automatic) -> Next.

6. On the New Azure service connection dialog. Select the available subscription,

and in resource group select SkillMeUpRG. Name the connection AzureSub and
click Save.

zoom image
Task 3: Configuring the Parts Unlimited project
1. Navigate back to your Parts Unlimited team project in Azure DevOps.

2. Before digging into creating our YAML pipeline, let’s disable the existing build
pipeline which came with the demo content.

3. Navigate to Pipelines.

zoom image
 4. Click on the name of the existing pipeline to open it. Then, click the ellipse
dropdown menu at the top right, and click Pause pipeline. We don’t want to
delete it, just prevent it from running.

zoom image

Task 4: Adding a YAML build definition

Now we’re ready to create our YAML build definition.

1. Navigate to the Pipelines hub.
 zoom image

2. Click New Pipeline. We will use the wizard to automatically create the YAML
definition based on our project.

zoom image

3. Select the Azure Repos Git as the source hosting platform. Note that others are
supported.

zoom image

4. Select the PartsUnlimited repo.
 zoom image

5. Select the ASP.NET template as the starting point for your pipeline.

zoom image

6. Review the contents and structure of the YAML definition. As you can see from
the breadcrumb at the top, it will be saved as a new file called “azure-
pipelines.yml” in the root of the repository, and it contains 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.

zoom code

copy code

name: Hosted VS2017

demands:
- msbuild
- visualstudio
 - vstest
Make sure all of the properties of pool are indented appropriately (using a two
space indention, including the sub properties of  demands), as shown in the
screenshot below:

zoom image

7. Next, you will modify the the msbuild arguments in the VSBuild task, to create
the output of the build in the artifactsStagingDirectory.

For this, we need to scroll down to the steps section of the YAML.

8. Find the VSBuild@1 task under steps and navigate to the end of

the msbuildargs: line. Change the command
from /p:PackageLocation to /p:OutDir.

The end of the command should look like this:

zoom image

9. The next task listed should be @VSTest@2. Below its inputs, make a new,

unindented line, where we will be creating a new, separate task.

Place your cursor on the new line and on the Tasks pane (you may have to
click Show Assistant) select Archive Files.

zoom image
Specify the following for Root folder - this is the location of the output to
archive:

zoom code

copy code

$(Build.ArtifactStagingDirectory)/_PublishedWebsites/partsUnlimitedWebsite
Make sure that the Archive file to create field looks like the below, this will
create a new zip with the build id as the filename.

zoom code

copy code

$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
Ensure Replace existing archive is checked and click Add.

zoom image
 Make sure your newly inserted YAML looks as shown in the screenshot. The Tasks
assistant indents based on where your cursor was, so if you were not on a blank
new line, you may need to make adjustments to match the below.

zoom image

10. In this YAML document we now have a build task, a test task, and an archive task
defined. Click Save and run.

zoom image
11. Click Save and run to confirm the commit of your updated .yml file to the project
repository. Add a description of your changes if you wish.

zoom image

12. Track the build until it completes. Each step will be shown, along with any
warnings or errors encountered. Your build should complete successfully, though
you will get a warning suggesting you further optimize by running operations
asynchronously.

13. You can click on your job to see each task from the YAML file, available for
review, including any warnings and errors, and how long each step took to
complete.
 zoom image

14. Select the Tests tab.

zoom image

15. The tests should now reflect succeeded as expected. The default filters may only
show you failures and aborted tests. You can adjust these at the top right to see a
report similar to this screenshot.

zoom image
Task 5: Adding continuous delivery to the YAML definition
1. Now that the build and test processes are successful, we can now add continuous
delivery to our YAML definition. From our new pipeline’s overview, select Edit
pipeline.

zoom image

2. 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.

zoom code

copy code

stages:
- stage: Build
jobs:
- job: Build

zoom image
3. Highlight everything in the YAML file after your new stages section, and indent it
four spaces by pressing tab twice. This will simply take the existing build
definition and relocated it as a child of the jobs node.

zoom image

4. At the bottom of the file, on a new unindented line, add the configuration below
to define a separate Deploy stage stage.

zoom code

copy code

- stage: Deploy
jobs:
- job: Deploy
steps:

zoom image
5. Set the cursor on a new line at the end of the YAML definition. This will be the
location where new tasks are added.

zoom image

6. Select the Azure App Service Deploy task.

zoom image
7. Select the Azure service connection you created earlier. Then update the package
or folder setting tp the following value:

zoom code

copy code

$(System.ArtifactsDirectory)/**/$(Build.BuildId).zip

zoom image

8. 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.

zoom image
9. 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.

zoom image

10. 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.

zoom image
11. Accept the defaults and click Add. This will publish the build artifacts to a
location that will be downloadable under the alias drop.

zoom image

12. Just as we did with the original build steps, indent the new publish task four
spaces (two tabs) to make it a child of the build stage. You may also want to add
an empty line before and after to make it easier to read.

zoom image

13. Make a new line under the steps node of the Deploy stage (before your

Deployment task) and place your cursor at the beginning of the line and then
indent 6 spaces (3 tabs).

zoom image
14. Search the tasks for “download build” and select the Download Build
Artifacts task.

zoom image

15. The Download build artifacts will not populate with the “drop” artifact you just
created automatically. You can type it in, or leave it blank and add it, which we’ll
describe in the next step. Click Add

zoom image
16. Make a new line after ‘single’, and add the following text in the YAML to point at
the artifact alias we created previously. Ensure your indentation matches the
previous line.

zoom code

copy code

artifactName: 'drop'

zoom image
17. Click Save to commit the changes.

zoom image

18. Confirm the Save. Because this is updating our repository, this will begin a new
build automatically.

zoom image

19. Return the Pipelines view.

zoom image
 20. Open the pipeline to view it’s current build status.

zoom image

21. When the Build stage completes, click the Deploy stage to follow each task.

22. Expand the AzureRmWebAppDeployment task to review the steps performed

during the Azure deployment. Once the task completes, your Parts Unlimited app
will be live in Azure!

zoom image

Task 6: Reviewing the deployed site

Let’s take a look at what we’ve deployed.
1. Return to the Azure portal browser tab.

2. Navigate to the app service created earlier.

3. Select the Configuration tab.

zoom image

4. Click the defaultConnection setting.

zoom image

5. 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 Update.

zoom image
6. Click Save to apply the changes.

zoom image

7. Return to the Overview tab.

zoom image

8. Click the URL to open your site in a new tab.

 zoom image

9. The deployed site should load as expected.

zoom image

10. Congratulations! You just defined a pipeline using YAML and deployed an
application using Azure DevOps.