In this presentation we exploring how teams across the enterprise can leverage Azure DevOps' by diving into its different capabilities and services. Specifically in the context of Azure platform teams that can leverage agile and DevOps practices when deploying and supporting services within Azure.

1. Leveraging Azure DevOps
across the Enterprise
Andrew Kelleher
December 2018
https://www.linkedin.com/in/ajkelleher/
http://medium.com/azure-architects

2. ◇ The journey to the cloud is rapidly evolving the technologies
and tools we use and just as importantly, how teams within
an organisation interact with each other
◇ This presentation explores the different features within
Microsoft Azure DevOps and demonstrates it’s value outside
its historical remit of application development
◇ We focus on how teams that are responsible for deploying
and managing services and environments within Azure can
also leverage Azure DevOps.
2
Introduction

3. Background
Cloud transformation projects are often managed through a collection of project
plans, spreadsheets and documents. This creates several challenges -
◇ Changing requirements and ad hoc requests
◇ Multiple vendors and ISV's
◇ Teams distributed across multiple geographic locations
◇ Inability to collaborate effectively due to disparate technologies
As part of this Azure platform teams often work across different Azure-related
activities –
◇ Core Azure infrastructure, database and network configuration
◇ Migrating IaaS workloads
◇ Re-platforming legacy applications
◇ Provisioning environments for developers
◇ Monitoring and operational activities
3

4. As agile practices start to extend outside developer teams
and into the wider business, platform teams can also gain
considerable value in adopting those agile and DevOps
methodologies.
Azure DevOps (AzDO) can be used by those teams to –
◇ track and plan activities
◇ store ARM templates and scripts
◇ manage Azure deployments
We'll take a look at the different services within AzDO, how
they can be leveraged for deployment + configuration
activities and some lessons learned.
4
An organisation’s “Azure platform” team is often a multi-discipline team that
has capabilities across infrastructure, databases, networking and security
How can Azure DevOps help?

5. AzDO “Organisations”
Before we dig into the different services let’s cover off the organisational concepts within
AzDO -
◇ Organisation - a "container" for an organisation’s AzDO projects
◇ Projects - reside within a single organisation. It's possible to have many projects within
a single organisation
◇ Teams - a project can contain multiple teams to segregate backlogs and track activities
5
Some companies have multiple
organisations and as an end user
it's possible to be a member of
multiple teams across multiple
projects located in multiple
organisations!
In this example the MyWidgets company has a single AzDO
organisation, with multiple projects and teams.

6. AzDO Dashboards
Dashboards provide the ability to share real-time progress and status across your team or
project. Dashboards are fully customizable using built-in widgets.
6
Dashboards can link widgets to your own
custom queries. For example you could have
a widget that displayed the total number of
completed tasks (backlog items) over the last
7 days.
Use Dashboards to -
◇ List the backlog items that
are assigned to you
◇ Track progress against test
plans
◇ Status of your build and
release pipelines

7. AzDO Wiki
The Wiki provides a convenient location for your project team to distribute information and
share knowledge.
The Wiki can add value by making key information easily accessible not only within your
team but across the organisation
7
The Wiki supports markdown so you can easily add links, tables and
images.
Useful information to include -
◇ Azure naming standards
◇ Tagging requirements
◇ Descriptions of build and
release pipelines
◇ Descriptions of key Azure
resources i.e. backup vaults,
log analytics workspaces etc.
◇ Documentation for any key
ARM templates within the
project's repositories
◇ Operational information
◇ FAQ's

8. AzDO Boards
Boards enable you to track and plan tasks and activities. If you're familiar with Agile
project methodologies then you'll feel right at home.
A board is essentially a Kanban board that helps you visualise your team's backlog work
items.
Even though boards were originally intended for app dev teams they can work well for
other types of projects.
8
Key things to note for boards are -
◇ New work items get created on the left
and move to the right as they're
completed and marked as "done"
◇ Columns are customisable and new ones
can be added
◇ Work items and tasks can be assigned to
individuals (they'll get an email notification
when this happens)
◇ Tag people using @name to notify
someone, request comments etc.
◇ Create tasks within a work item to group
similar activities

9. AzDO Sprints
Boards are a good starting point for tracking activities but they're also a bit ad hoc.
Therefore it's possible your team will want to plan when certain activities get worked on.
Traditionally, waterfall project methodologies are used where there is a sequential, linear
approach to completing activities.
Sprints take a different approach by adopting a time-boxed cycle of work; 2-3 weeks per
sprint is common and normally less than 4 weeks.
For each sprint the product owner and team agrees what work items should be moved
from the product backlog into the sprint backlog. During that sprint the team will focus on
those agreed items.
9
This is a common approach for app dev teams but there's also potential to utilize
sprints for Azure platform focused teams….

10. AzDO Sprints cont.
As an example take the following scenario –
◇ You're part of a platform team that is supporting several cloud transformation initiatives
within your organisation
◇ You've got lots of competing requests for Azure environments, infrastructure
configuration etc.
◇ Some of these activities may only take a few hours whilst others may take a few days or
longer.
10
Leveraging sprints -
◇ By agreeing which activities and requests your team works on
during the next sprint you'll be able to efficiently prioritize the
most important activities.
◇ At the end of the sprint you'll complete a sprint review to review
what work was completed, what worked well etc
◇ You then enter into sprint planning for the next sprint to agree
what activities will be focused on next.
Recommendation: start with a simple board and if additional
structure or planning is needed look at leveraging sprints as
needed.

11. AzDO Repositories
Repos provide a shared AzDO-hosted Git repository for all of your ARM templates and
PowerShell scripts.
Being Git based you have the ability to create branches, commit code and create pull
requests into a master branch.
11
Things to consider -
◇ Use Visual Studio Code as your IDE for tight
integration with AzDO
◇ You can have multiple repos within an AzDO
project - create a dedicated "infrastructure" repo
for core Azure services
◇ Agree a branching strategy i.e. use feature
branches when updating / creating new ARM
templates
◇ Assess whether approvals and reviews are
needed when pulling updates into the master
branch
◇ Agree how to structure the repo folder structure The example above shows a folder structure for the ARM templates
that aligns to the different Azure provider names

12. AzDO Build Pipelines
A build definition automatically builds and validates the code in our repository. As our
“code” is consists of ARM templates and PowerShell scripts our build can be relatively
simple. In the example below our build has two tasks which -
1. Copies the content of our infrastructure repository
2. Publishes the content as an "artifact"
12
Considerations -
◇ Think of the build artifact as a snapshot of our
repo which we'll reference from our release
pipelines.
◇ Once created, a simple build pipeline
shouldn’t need re-configuring that often
◇ Enable Continuous Integration (CI) on the
build pipeline to ensure that when an ARM
template or script is updated within the
repository a new build is automatically created
that contains the updated code

13. A release pipeline provides a way to selectively deploy the ARM templates or scripts
contained within our build artifact.
For example, if we need to deploy an Azure site-to-site VPN into each of our
subscriptions (Sandbox, PreProd, Prod) we'd create a release pipeline similar to the one
below -
13
In this example we named our stages according to the different Azure subscriptions
we're deploying into. But if you're deploying an application environment these might be
named Dev/Test/UAT/PreProd/Prod etc.
AzDO Release Pipelines (1/3)

14. Within each stage we have a single Azure Resource Group Deployment task that deploys
the S2S VPN ARM template from our build artifact -
14
This is a basic pipeline but there's a
rich ecosystem of tasks that can be
added as required to create a
complex pipeline. An example
would be deploying an application
environment containing multiple
VM's, networks, load balancers and
databases.
AzDO Release Pipelines (2/3)

15. Whilst we may only need one general purpose infrastructure build, it's likely you'll end up
with multiple release pipelines that reference it. For example, you may end up creating
individual pipelines for deploying ExpressRoute circuits, virtual networks + subnets,
storage accounts, log analytics workspaces etc.
Some of these resources you'll typically only want to deploy once i.e. an ExpressRoute
circuit. Others may be updated semi-regularly i.e. additional subnets added to a VNET.
The latter workflow is outlined below -
15
Create a new feature
branch in the
infrastructure repo i.e.
feature/subnetupdate
Update the ARM
template for your
subnets within that
feature branch
Pull the feature
branch into the Master
branch
Updated build is
automatically created
with updated ARM
templates
Create a new release
for the VNET pipeline
and deploy using the
new build
Subnet configuration
within Azure is
updated
Other considerations for release pipelines include -
◇ How to structure and name the stages i.e. per subscription or per environment
◇ Stage approvals; leverage these to ensure that only certain individuals can approve a deployment
(especially for production!)
◇ Store secrets and certificates for your pipelines in Key Vault
◇ Use the Wiki to document any particularly complex pipelines
AzDO Release Pipelines (3/3)

16. AzDO Test Plans (1/2)
When deploying ARM templates via AzDO there's commonly two types of testing we want to perform -
1. Deployment testing i.e. has the template successfully deployed?
2. Post-deployment testing i.e. are the deployed Azure services operating as we'd expect?
For the first type of testing the release pipeline will automatically generate errors if the template
deployment fails. There are also additional tasks we can integrate such as Pester and the Secure
DevOps Kit to perform further validation.
For post-deployment testing we can leverage AzDO's test plans. These provide the ability to write and
track manual testing activities.
16
Using the site-to-site VPN example let's
assume our release pipeline has
successfully deployed the required Azure
services. We now want to perform a series
of manual tests to validate that the
connection is operational. These tests
might include -
◇ Validate the VPN connection status is
"connected"
◇ RDP connectivity from on-premise to
an Azure VM
◇ ICMP ping test from on-premise to an Example test plan showing the test cases we’ve written

17. AzDO Test Plans (2/2)
When ready to start testing, select run and AzDO's web-based test runner application fires
up and guides us through the test steps -
17
Key benefits of Test Plans are -
◇ Test cases can be linked to work
items
◇ Bugs can be created from failed
tests
◇ The Test Runner interface
makes it easy to grab
screenshots and screen
recordings
◇ It's all within AzDO - no test
spreadsheets or 3rd party tools
required!
Example test plan showing the test cases we’ve written

18. Summary
This presentation provides a very high-level overview of the services available within AzDO. But hopefully
it gives you a flavour of what's possible outside its historical remit of a tool to support application
development.
By utilizing the services within AzDO an Azure platform team will become -
◇ More efficient, transparent and responsive across its activities
◇ Be more effective when planning work
◇ Enable a single, managed and end-to-end approach for Infrastructure as Code
◇ Ensure the proper governance is wrapped around Azure deployments
This presentation has been written in the context of a single Azure platform team. However, many
organisations aren’t structured in this way and have those Azure skills dispersed amongst a more
traditional team structure i.e. infrastructure, network, storage etc. In those scenarios I believe those teams
will gain even greater benefit from AzDO— by working out of a single, common tool they’ll be able to work
more effectively together.
You don't have to go all in at once either, utilising Repos and Pipelines is a good place to start. Start to
explore the other services and find what works for you and your team.
18

19. Further Reading
◇ Microsoft Azure DevOps Documentation
◇ Tutorial: Creating your first build and release pipelines
◇ Video: Deploy an ARM template using VSTS based on VSTS but still has some useful
guidance
◇ Video: Deploy ARM template to Azure using Azure DevOps
◇ Labs: Azure Citadel lots of labs on DevOps, containers and AzDO
◇ Microsoft.com/learn new Azure learning portal with different paths and modules
◇ Free eBook Enterprise Cloud Control Plane Planning
19