Practice Effective DevOps with Azure DevOps

LOGAN RAKAI - March 30th, 2020

Azure DevOps is a suite of services that collaborate on software development following DevOps

principles. The services in Azure DevOps are:

1. Azure Repos for hosting Git repositories for source control of your code

2. Azure Boards for planning and tracking your work using proven agile productivity tools

3. Azure Pipelines for continuous integration and delivery of your software

4. Azure Test Plans for testing your software

5. Azure Artifacts for publishing software packages

There are different plans available for using Azure DevOps. There are generous free limits that

allow you to get your hands dirty and try out a lot of what Azure DevOps has to offer. Rather than

just tell you about Azure DevOps, you will see first-hand how Azure DevOps works and what you

can use it for in this post.

You will use services within Azure DevOps for everything in this demonstration. However, you can

pick and choose the pieces you want to use and integrate them with external tools that you may

already be using. Azure DevOps was built to support that level of customization and you will see

several places where you have options to integrate with tools outside of Azure DevOps.

Creating Your Azure DevOps Project

Introduction

Azure DevOps services are accessed through Azure DevOps projects. Each project is part of an

Azure DevOps organization. You can manage settings shared across all projects at the

organization-level and manage finer-grained controls at the project-level. This demonstration

focuses on the project level. You will create a basic plan Azure DevOps project now which

automatically creates an Azure DevOps organization. The basic plan includes access to four Azure

DevOps services:

1. Azure Boards

2. Azure Repos

3. Azure Pipelines

4. Azure Artifacts

There are limits to what you can do with the services in the basic plan but it is entirely free if you

have 5 or fewer users. Everything you will do in this demonstration is well within the limits of the

basic plan so follow along without worry. Delete the organization once you are finished and you

will not have any charges to worry about. The instructions below create a new Microsoft account

to avoid incurring charges on an existing Azure DevOps organization you may already be a part of.

Instructions

1. Navigate to dev.azure.com.
You can find a summary of each tool in the Azure DevOps suite from this page as well as the links

to create an account or to sign in.

2. Click Start free to begin registering your account.

You can also click Sign in to Azure DevOps if you have an existing Microsoft account that you want

to use. If you are currently signed in to a Microsoft account you will be able to select that account

rather than creating a new one if you choose.

3. Click Create one to create a new account:

Notice you can also directly Sign in with GitHub accounts.

4. Click Get a new email address:

5. Enter a value for New email and click Next:

6. Enter a password and click Next:

7. Solve the challenge to confirm you are not a robot and click Next to create your account.

You are automatically taken to the Azure DevOps registration process.

8. Select your Country and click Continue:

This kicks off the process of creating a new Azure DevOps organization with a name based on your

email address. Your organization is a container for your DevOps projects. The free tier limits for

Azure DevOps apply to the organization as a whole and not each project if you have multiple

projects.

9. Enter a name for your project and click Create project:

It is possible to create Public projects. Public projects allow anyone read-only access to the

project. Only invited members can view private projects. Members are added to either type of

project with permissions assigned to control their level of access. It is possible to change the

project visibility after the project is created (unless you disable public projects in your organization

settings).

Your project Summary view is displayed once the project is created:

The project automatically adds you as the only member of the project.

Summary

You have created an Azure DevOps project using a shiny new Microsoft account. The project is

running for free under the basic plan.

Adding an Azure Repo to Your Project

Introduction

Azure Repos are Git-based repositories in the Azure DevOps tool suite. You can have an unlimited

number of private Git repos for free. On top of the Git repository is an array of features to

integrate repos with workflows and making it easier to manage your code and related processes.

Some of the features include pull request-based workflows, branch policies to enforce high quality

of merged code, and semantic-aware code search. As a Git-based repo, you can use all of your
favorite tools that support Git with repositories in Azure repos. You will create a private repo in

your Azure DevOps project now.

Instructions

1. Click Repos in the sidebar:

The options available to you for starting the project’s currently empty repo are described:
You will import a repository to stay focused on Azure DevOps. You could also use your favorite

integrated development environment (IDE) with Git support to directly connect with your repo by

cloning or pushing an existing Git repository.

2. Click Import.

3. In the Import a Git repository blade enter https://github.com/cloudacademy/example-git-repo.git as

the Clone URL before clicking Import:

Besides importing Git repositories, there is also built-in support for migrating Team Foundation

Version Control (TFVC) to Git.

In a few moments, the repository is imported and the Files view appears:
The repo is a static website consisting of HTML, CSS, and JavaScript files. The Repos UI allows you

to view/edit files, visualize commit history, compare branches, manage pull requests, and just

about everything you’d expect from a full-featured Git repository. You will work with branches and

pull requests later on.

4. Click Commits in the sidebar.

Observe the commit graph and see how it visualizes the update title commit on a separate branch

and pull request to merge it into the master branch:

5. Click the update title commit to view the file diff of the commit:
Feel free to roam around the Repos UI to discover more of what you can do.

Summary

You now have a private Git Repo hosted in Azure Repos. You have seen some of the nice interface

features in Azure Repos and you will see how nicely Azure Repos integrate with other Azure

DevOps services in what follows.

Tracking Your Work with Azure Boards

Introduction

Azure Boards provide tools for planning, tracking, and collaborating using agile tools. Boards

support several processes including Scrum and Agile. Each process can plan and prioritize work in

backlogs, keep a limit on work in progress on kanban boards, organize and track work in sprints,

and use analytics to optimize your agile processes. In Azure Boards, you use work items for

everything you need to track. Work items represent different types of work such as epics, issues,

or tasks. Work items can also have relationships with other work items, such as parent-child.

There are a variety of views for work items. Each provides you with an optimized view for different

tasks at hand. You will use Boards to plan out a simple product launch in this demonstration.
Instructions

1. Click Boards in the sidebar:

This takes you to the Work items view:

This view allows you to find recently updated work items. At this point, there are no work items on

your board. The other board views give you different ways to view and organize work items. You

can add work items from all but the Queries view. You will begin by adding work items to a backlog

and then visualizing the work on the kanban board.

2. Click Backlogs:
With the default configuration for a project following the basic process (other built-in processes in

Azure DevOps are Scrum, Agile, and CMMI) there are backlogs for Epics and issues. If, for example,

you configured the process for the project to be Scrum, there would be feature and backlog items

backlogs.

3. Ensure Epics is selected in the drop-down menu and click New work item.

4. Enter Product Launch as the title and click Add to top:

You will make an epic for the launch of a website. You will create two child work items in the epic

for the work required to launch.

5. Click the Product Launch title to edit its details:

Take a moment to observe what functionality is available in the details view:

You can add a Description, prioritize, schedule, comment, post comments in the Discussion, add

attachments, set the State, assign an Iteration, among other things.

6. Set the following values before clicking Save:

● Click Unassigned in the drop-down menu and assign the epic to yourself

● Set the Start Date to today

● Set the Target Date to tomorrow

7. Under Related Work, click Add link > New item:

You will now add the tasks required to complete the launch epic as child items.

8. Set the following values in the Add link form before clicking OK:

● Link type: Child

● Work item type: Task

● Title: Update website content

Notice the variety of Link types available to you for describing relationships between work items.

9. In the Task details pop-up, set the following values under Planning before clicking Save & Close:
 ● Activity: Development

● Remaining Work: 2 (the units of work represent hours by default)

10. Add a second related child item of the epic that is a Task named Create release pipeline and set

the following Planning properties:

● Priority: 1

● Activity: Deployment

● Remaining Work: 3

You will create an Azure Pipeline to deploy your website using containers and before customizing

the website content.

11. Click Boards and ensure Epics is selected in the drop-down menu:
The basic process template uses a simple three-state board: To Do, Doing, Done. Other processes

have different default states and you can always customize to best suit your team’s workflow

requirements. For example, adding a review or test state. Following the kanban tenet of limiting

work in progress, the Doing column shows 0/5 representing a limit on the number of items in the

Doing state at any given time. You can customize the work in progress limit in the board settings

12. Drag the Product Launch epic to the Doing column and observe the work in progress

increments to 1/5 and the card’s state changes to Doing:

You will now focus in on the tasks related to the epic in the sprint view.

13. Click Sprints:

Only Sprint 1 is available and that is all you will need for this example. To get the benefit of

analytics you will need to configure a few sprint properties.

14. Click No iteration dates in the upper-right corner and set the following values before clicking

Save and Close:

● Start date: Select today from the calendar

● End date: Select tomorrow from the calendar

That is enough to get started. You are able to set capacities of team members for each activity type

and include days off to increase the accuracy of analytics.

15. Click Taskboard and drag the Create release pipeline task to the Doing column:
You will start working on the release pipeline next.

Summary

You have created an Azure Board for a product launch. You saw how to populate a backlog, keep

track of work in progress on the kanban board, and organize work items into a sprint. The default

basic process is simple and easy to get started with although other processes are supported and

there are many ways to customize Boards to fit your own work requirements. You will see later on

how other Azure DevOps services directly integrate with Boards.

Creating a Build Pipeline in Azure Pipelines

Introduction

Azure Pipelines is the Azure DevOps service for continuous integration and continuous

deployment. At a high-level, there are two distinct types of pipelines in Azure Pipelines, which can

be confusing if not made aware of early on. There are build pipelines, sometimes referred to simply

as pipelines in the UI, and release pipelines. The build pipelines are focused on the continuous

integration of source code while release pipelines are focused on continuous deployment.
Although build pipelines can also deploy code, they should only be used to deploy to development

or test environments. Your production deployments are better performed using release pipelines.

Build pipelines connect to a code repository and perform a build to produce build artifacts. You

will see how build pipelines are a generic tool that can integrate with any Git-based repository and

can satisfy any of your build requirements. The build is described in a YAML file that is included in

the repo. You will perform a simple build that archives the code in your Azure Repo.

Instructions

1. Click Pipelines in the sidebar:

2. Click Create Pipeline.

This kicks off the build pipeline wizard.

3. In the Connect step, select Azure Repos Git for the source of your code:
Not the other sources that can be integrated with Azure Pipelines. Azure DevOps makes it easy

for you to use just what you need in Azure DevOps and allows you to continue using whatever

external tools work best for you. There is also the option to Use the classic editor for a graphical

interface although YAML build pipelines are recommended.

4. In the Select step, choose your repo.

5. In the Configure step, click Show more to reveal all the template pipelines available.
There are templates targeting Windows, Linux, and Mac platforms, a wide variety of programming

languages, and container platforms:

6. Click HTML.

The HTML pipeline template appears in the Review step:

The “build” for the static website repo is simply to archive all of the files but it is enough to

illustrate how the YAML pipelines are constructed:

● trigger: This section specifies which events trigger a build. The default is any push to the

master branch triggers the pipeline. You can configure pushes, pull requests, and

scheduled triggers. Removing the trigger list causes any push or pull request to trigger a

build.

● pool: Specifies which build agent pool to use. You can use Microsoft’s Windows, Linux, and

Mac agents or your own self-hosted agents. In the template, the latest ubuntu agent

hosted by Microsoft is used.

● steps: describe the individual tasks and their order in the stage of the pipeline. The

template includes a task for archiving/zipping the files (ArchiveFiles@2) and one for

publishing the build artifacts (PublishBuildArtifacts@1) which is the zip file in this case.

There is a catalog of built-in tasks covering most build scenarios and includes PowerShell
 and shell script tasks to run arbitrary commands. You can also add custom tasks if the need

arises.

You can reference the pipeline schema documentation to learn about all the capabilities of YAML

pipelines including variables and multi-stage pipelines.

7. Click Show assistant to reveal the assistant that allows you to easily add additional steps

without writing any YAML.

Browse through the available tasks but don’t add any to your pipeline.

8. Delete the trigger list so any push or pull request triggers a build and click Save and run:

9. Click Save and run in the commit blade:

This will commit directly to master. You will see an example of the branch and pull request flow

later on.

The build is queued and usually begins running within a few seconds. Once completed you can see

the Success status and 1 published build artifact:

Clicking the Job reveals the build steps and associated logs. Clicking the 1 published artifact

reveals the published zip archive. This artifact can be used to trigger a release pipeline, which you

will see next. It is also worth noting that these build artifacts are different from Azure Artifacts,

which appear in the Artifacts sidebar. Azure Artifacts are part of Azure DevOps devoted to

publishing NuGet, npm, and Maven packages.

Summary

You have defined a build pipeline for your codebase in Azure Pipelines. Although you used an

Azure Repo, any Git repository can be used with Azure Pipelines. You saw how flexible the YAML

pipelines are and can include a variety of step types for whatever your builds require. You will see

how release pipelines differ from build pipelines next.

Creating a Build Pipeline in Azure Pipelines

Introduction

Azure Pipelines is the Azure DevOps service for continuous integration and continuous

deployment. At a high-level, there are two distinct types of pipelines in Azure Pipelines, which can

be confusing if not made aware of early on. There are build pipelines, sometimes referred to simply

as pipelines in the UI, and release pipelines. The build pipelines are focused on the continuous

integration of source code while release pipelines are focused on continuous deployment.

Although build pipelines can also deploy code, they should only be used to deploy to development

or test environments. Your production deployments are better performed using release pipelines.

Build pipelines connect to a code repository and perform a build to produce build artifacts. You

will see how build pipelines are a generic tool that can integrate with any Git-based repository and
can satisfy any of your build requirements. The build is described in a YAML file that is included in

the repo. You will perform a simple build that archives the code in your Azure Repo.

Instructions

1. Click Pipelines in the sidebar:

2. Click Create Pipeline.

This kicks off the build pipeline wizard.

3. In the Connect step, select Azure Repos Git for the source of your code:
Not the other sources that can be integrated with Azure Pipelines. Azure DevOps makes it easy

for you to use just what you need in Azure DevOps and allows you to continue using whatever

external tools work best for you. There is also the option to Use the classic editor for a graphical

interface although YAML build pipelines are recommended.

4. In the Select step, choose your repo.

5. In the Configure step, click Show more to reveal all the template pipelines available.
There are templates targeting Windows, Linux, and Mac platforms, a wide variety of programming

languages, and container platforms:

6. Click HTML.

The HTML pipeline template appears in the Review step:

The “build” for the static website repo is simply to archive all of the files but it is enough to

illustrate how the YAML pipelines are constructed:

● trigger: This section specifies which events trigger a build. The default is any push to the

master branch triggers the pipeline. You can configure pushes, pull requests, and

scheduled triggers. Removing the trigger list causes any push or pull request to trigger a

build.

● pool: Specifies which build agent pool to use. You can use Microsoft’s Windows, Linux, and

Mac agents or your own self-hosted agents. In the template, the latest ubuntu agent

hosted by Microsoft is used.

● steps: describe the individual tasks and their order in the stage of the pipeline. The

template includes a task for archiving/zipping the files (ArchiveFiles@2) and one for

publishing the build artifacts (PublishBuildArtifacts@1) which is the zip file in this case.

There is a catalog of built-in tasks covering most build scenarios and includes PowerShell
 and shell script tasks to run arbitrary commands. You can also add custom tasks if the need

arises.

You can reference the pipeline schema documentation to learn about all the capabilities of YAML

pipelines including variables and multi-stage pipelines.

7. Click Show assistant to reveal the assistant that allows you to easily add additional steps

without writing any YAML.

Browse through the available tasks but don’t add any to your pipeline.

8. Delete the trigger list so any push or pull request triggers a build and click Save and run:

9. Click Save and run in the commit blade:

This will commit directly to master. You will see an example of the branch and pull request flow

later on.

The build is queued and usually begins running within a few seconds. Once completed you can see

the Success status and 1 published build artifact:

Clicking the Job reveals the build steps and associated logs. Clicking the 1 published artifact

reveals the published zip archive. This artifact can be used to trigger a release pipeline, which you

will see next. It is also worth noting that these build artifacts are different from Azure Artifacts,

which appear in the Artifacts sidebar. Azure Artifacts are part of Azure DevOps devoted to

publishing NuGet, npm, and Maven packages.

Summary

You have defined a build pipeline for your codebase in Azure Pipelines. Although you used an

Azure Repo, any Git repository can be used with Azure Pipelines. You saw how flexible the YAML

pipelines are and can include a variety of step types for whatever your builds require. You will see

how release pipelines differ from build pipelines next.

Creating a Release Pipeline in Azure Pipelines

Introduction

Although there are tasks for deploying build artifacts in build pipelines, there is more support for

releases in release pipelines including automatic rollbacks. When releasing to production

environments release pipelines are recommended. You can include manual approvals and gates

within a release pipeline to protect your release environments. You will define a release pipeline

that will automatically trigger when a pull request is made to the master branch of your Azure

Repo. The release pipeline with use the build artifact produced by the build pipeline as its input.

Instructions

1. Click Releases in the sidebar:

2. Click New Pipeline.

This will display a blade with a variety of templates to choose from:

Browse through the templates. You will create a simple release pipeline but know there are

templates for a variety of deployments in Azure and externally such as to a Kubernetes cluster. It

is also possible to save your own release pipelines as templates and import/export release

pipelines in JSON format.

3. Click Empty job at the top of the blade to start with a pipeline without any steps defined.

A Stage blade appears with the default name of Stage 1:

You will build out the pipeline by defining the artifacts that trigger the release and add tasks to the

Stage 1 job that is currently empty.

4. Click + Add an artifact and click the drop-down to expand all the available artifact sources:
The Build option is appropriate in this case because you will release using the build artifact

created by the build pipeline. However, you can trigger a deploy directly from Azure Repos.

Several sources outside of Azure are also available allowing you to plug-in release pipelines with

your preferred external systems.

5. With Build selected, set the following values (leaving the defaults for the rest) before clicking

Add:

● Project: Select your project from the drop-down menu

● Source: Select your build pipeline from the drop-down menu

The information tip at the bottom tells you the drop artifact will be used for each successful build.

By default, the build artifact is named drop.

6. Click the lightning bolt on the artifact to configure a continuous deployment trigger for the

release:
As an example, you will configure a deployment every time a pull request created from a feature

branch. This would allow you to view a deployment associated with a pull request to help with

reviewing the code included in the pull request. You can also always manually deploy a release

regardless of the continuous deployment configuration.

7. In the Continuous deployment trigger blade, click the Pull request trigger slider and set the

following values:

● Target branch: master

You can also configure deployments whenever a build is available. The information tip at the

bottom tells you which stages are configured to run with a pull-request trigger. This gives you the

flexibility to choose which stages run for releases triggered by a pull request. You will configure

the only stage currently available to run with the pull request trigger.
8. Close the trigger blade and click the lightning bolt on the Stage 1 element:

In the Pre-deployment conditions blade you can configure a variety of conditions to specify when

the stage will execute:

Amongst other things, you can set users who are allowed to manually approve or reject

deployment, use Gates, such as running a security scan, before allowing the stage to run. You can

make stages Manual only as well.

9. Toggle Pull request deployment to Enabled before closing the blade.

10. Click 1 job, 0 tasks under Stage 1 to edit the stage tasks.

11. Click Agent job and observe this is where you can configure the Agent pool, Agent

specification (whether you want Windows, Linux, or Mac for example), and whether the stage

should run only when previous stages succeed, etc.

The default values will work for this example.

12. Click the + icon to the right of Agent job to open the task catalog:

There are hundreds of tasks to choose from including many from third-parties through the

Marketplace. You will add tasks to download the build artifacts and echo the title from the

index.html file. Although this isn’t a real release it will illustrate how to develop release pipelines.

13. Add the Download build artifacts task followed by the Bash task:
The left stage visualization should now look like this:

14. Click Download Build Artifacts and set Download type to Specific files and leave the rest at

their defaults.

15. Click Bash Script and set the Type to Inline and enter the following in the Script field:
echo 'Releasing...'
cd drop
unzip -q *
grep '<title>' index.html

This will unzip the build artifacts and echo out the <title> tag line from the index.html file. This is

enough to describe the simple release pipeline, but you will also update the pipeline’s integrations

so release status details can be observed outside of Azure Pipelines.

16. Click the Options tab followed by Integrations:

By default, the deployment status is reported in the repository host (Azure Repos) interface.

17. Check each of the following before clicking Save and OK in the dialog that appears:

● Report deployment status to Work (create links to all work items that represent

associated changes to the source when a release is complete)

● Report deployment status to Boards and set the Deployment type to Production (work

items associated with commits in the build will show the status of the release)

● Enable the deployment status badge (URL that displays a badge for the release status)
18. Click Create release to manually trigger the release pipeline:

19. Click Create to accept the release will automatically run all stages and use the latest build

artifacts:
20. Click Release-1 in the notification bar that appears to view the release details:
21. Close any pop-up that appears and click Stage 1 to view its progress:

If you don’t see Succeeded within a minute, click the Refresh button.

22. Click View logs to view the agent logs:

You can view logs for each step of the stage including the two tasks you defined:

Observe the stage automatically includes a Download artifact step which is the same as the

Download Build Artifacts step you added except it downloads to a different directory (a
subdirectory named after the repo). You wouldn’t need to include both in a real pipeline but it was

useful for illustrating multiple release build tasks.

23. Click Bash Script and observe the <title> output at the end of the logs:

Also, note it was no problem to run a bash script on the Windows agent.

Summary

You created a release pipeline that will trigger when pull requests are made to the master branch

of your Azure Repo. The release consists of one stage with two tasks. You saw the extensive

amount of tasks that are available within Pipelines and from the Marketplace. There is a lot more

to release pipelines including multi-stage capabilities and using variables to adapt the release. You

can explore more about those capabilities on your own after the demonstration is complete.

Configuring an Azure Repos Branch Policy

Introduction
To fully support pull request workflow-based releases you need to configure a branch policy on the

master branch in Azure Repos that validates the code can build. The branch policy also allows to

require pull requests for the branch and set the minimum number of reviewers, and more.

However, you will configure the master branch policy to validate the code builds.

Instructions

1. Click Repos > Branches in the sidebar.

2. Hover over the master branch and click the three dots on the right followed by Branch policies:

Observe the available policy settings before continuing.

3. Click + Add build policy to validate the code in pull requests:

4. Select your Build pipeline from the drop-down and click Save:
The default setting requires that the build succeeds to complete pull requests.

Summary
You now have a branch policy for the master branch enforcing successful automatic builds for pull

requests.

Completing the Product Launch Epic

Introduction

With your release pipeline and branch policy in place, you are now ready to complete the Product

Launch epic by updating the website content. You will see how the pull request workflow works in

Azure DevOps along the way.

Instructions

1. Click Boards > Sprints in the sidebar.

2. Drag the Create release pipeline card to the Done column and drag the Update website

content card to Doing:

3. Click Update website content to open the card details.

You will create a branch and later create a pull request to the master branch to complete the work

item.
4. Under Development click create a branch and set the following values before clicking Create

branch:

● Name: feature/content-update

● Work items to link: Select the epic from the drop-down (the task is automatically linked)

You are taken to the Files view of the new branch.

5. Click the index.html file followed by Edit to edit it within the browser:
6. Add and Azure DevOps to the title and click Commit:

7. Link both work items to the commit before clicking Commit:

8. Click Pipelines > Pipelines to observe a new build has resulted from the commit:
9. Click Releases and observe there is no new release since only pull requests will result in an

automatic release with the current configuration.

10. Click Repos to return to the content-update files view and click Create a pull request:

Notice the succeeded status telling you the build succeeded from the repo view.

11. Observe the diff view at the bottom summarizing the changes before clicking Create:

You can also assign reviewers if other members were added to the project.
12. Observe the Status section on the right which transitions through the build status and finally

to New release pipeline succeeded:

This is the result of the branch policy and pull request release trigger.

13. Click New release pipeline succeeded to view the release.

14. Click Succeeded under Stage 1 and then view the updated title output by the Bash Script task:
This is enough to verify the release in this example.

15. Click Repos > Pull requests and click the only available pull request to return to the active pull

request.

16. Review the tabs available in the pull request view before clicking Approve followed by

Complete:

Approving automatically adds you as a reviewer.

17. Observe the different settings available before clicking Complete merge:

The default settings will cause the work items to be completed after merging and the

content-update branch will be deleted.

18. Click Boards > Sprints and observe the Update website content card is in the Done column.

The epic card is also automatically moved to Done on the epic kanban board.
19. Click Update website content to view the task details and observe the release and pull request

are both linked from the card because of the integrations configured earlier:

Summary

That completes the Product Launch epic and this tour through Azure DevOps. Although this

demonstration exclusively used Azure DevOps, you are free to use the pieces that are most

applicable to your needs. For example, if you like using GitHub for your code, you are free to use

only Boards and Pipelines without Repos. This high degree of configurability is also visible within

each Azure DevOps service. I’d encourage you to look at the Project Settings which are accessible

at the bottom of the sidebar:

This is where you can add members to projects, configure role-based access control, and much

more. You can also explore the Organization settings by clicking the Azure Devops icon in the

upper-right corner and clicking settings in the lower-right:

You can view billing, audit logs, usage, add extensions, configure your Boards process (Basic, Agile,

Scrum, CMMI) and a whole lot more from there. This is also where you can delete the organization,

which is recommended once you are finished exploring.

Azure DevOps also includes Test Plans, but they aren’t included with the free plan (although you

can get 30 days free). To learn more about Test Plans check out the product page.