skip to Main Content

Introduction to Azure DevOps

Azure DevOps is a suite of services to help with developer collaboration in respect to version control, building applications, DevOps processes and tools to help facilitate product planning, sprint management and backlogs.

Why is this important? The goal is to embrace the idea of DevOps. There are many definitions of what DevOps is but essentially the aim is to be collaborative and deliver business value fast and help break down silos between teams. Using a tool like Azure DevOps helps. The way software is developed is changing. It is quite common to see a more agile way of working to deliver benefit to the end customer faster.

Everything starts with source control then a natural movement into continuous integration (CI) can take place. This is where every developer on your team integrates their work into source control. This process also does basic checks such as verification of builds, compilation tests and unit testing. Once this piece has been implemented you can start to investigate continuous deployments (CD) where you automatically deploy the code (from source control) into your environments, upstream to production being the final goal. This is all done via Azure Pipelines. These are just a few components of Azure DevOps, there is much more to it. As you can see from the below screenshot you have other components such as dashboards, wikis, boards and test plans.

Azure DevOps Dashboard

Source Control

No matter where your code is, whether you use Git (distributed) or Team Foundation Version Control (TFVC) which is a centralized client-server system approach, this is where everything starts. Git in Azure DevOps is standard Git. You can use Visual Studio with third-party Git services, you can also use third-party Git clients with Azure DevOps.

Here we track all the history of changes we have made to our codebase whilst being separate from our developer colleagues.  Git, as indicated above is also known as a distributed version control system and was built from the ground up with the following goals in mind. Speed, support for thousands of parallel branches, fully distributed and to be able to handle very complex projects. Git is special and different in how it thinks about the files within its version control. Git thinks of it as a series of snapshots of a mini filesystem, more specifically a “stream of snapshots” as indicated below:

Storing data as snapshots

Reference: Page 19, ProGit 2021, Scott Chacon and Ben Straub

Side note, so how is GitHub linked? GitHub is the largest host for Git repositories and an industry-standard where many companies and developers collaborate for their mission-critical applications so you can see how they are related.

Once you have settled on the source control you want, as developers a decision is then needed on what sort of branching strategy you would like to use. The common ones are GitHub flow, release flow and Gitflow. Once you have formed up these elements you are ready to think about continuous integration and deployment.


As mentioned in the introduction the philosophy behind CI is to check in / integrate your code frequently with your team members. Ideally, this is as frequent as possible to preserve the quality of your code and to make sure no major conflicts exists. Normally this is the right time to apply basic unit testing and security scanning practices against your code.

The end goal is the production of build artifacts. This is used during the CD process where the application is automatically deployed to your target environment. With Azure DevOps, you would use pipelines. More specifically you could opt for the visual classic editor (GUI) or YAML based. I personally prefer the YAML approach and like the idea of build definitions as code – it is tightly integrated with your source control and you get the added benefits (such as to change something, issue a pull request and peer reviews are needed).

Using the combined elements discussed above a basic approach would be as seen below:


Azure DevOps in Action

For the practical element of the post, we will configure continuous integration and continuous deployment for an application via Azure Pipelines.

So obviously we need to connect to source control. Below I select the relevant location.

Where is your code?

YAML Pipeline

I then use YAML to build the pipeline.

Review your pipeline YAML

The final YAML file content is shown below.

The trigger is when we push to the master branch where then the jobs within the YAML code will execute. At a high level, we are building our application then using a build artifact to then publish to my Azure Web App, (these are split over a build and deploy job).

# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:

– master

– stage: Build
  – job: Build

      vmImage: ‘vs2017-win2016’

      solution: ‘**/*.sln’
      buildPlatform: ‘Any CPU’
      buildConfiguration: ‘Release’

    – task: [email protected]

    – task: [email protected]
        restoreSolution: ‘$(solution)’

    – task: [email protected]
        solution: ‘$(solution)’
        msbuildArgs: ‘/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=”$(build.artifactStagingDirectory)”‘
        platform: ‘$(buildPlatform)’
        configuration: ‘$(buildConfiguration)’

    – task: [email protected]
      displayName: ‘Copy Files’
        SourceFolder: ‘$(build.sourcesdirectory)’
        Contents: ‘**/*.json’
        TargetFolder: ‘$(build.artifactstagingdirectory)’

    – task: [email protected]
      displayName: ‘Publish Artifact’
        PathtoPublish: ‘$(build.artifactstagingdirectory)’
    – task: [email protected]
        PathtoPublish: ‘$(Build.ArtifactStagingDirectory)’
        ArtifactName: ‘drop’
        publishLocation: ‘Container’

– stage: Deploy
  – job: Deploy

      vmImage: ‘vs2017-win2016’
          – task: [email protected]
              buildType: ‘current’
              downloadType: ‘single’
              downloadPath: ‘$(System.ArtifactsDirectory)’
              artifactName: ‘drop’

         – task: [email protected]
              ConnectionType: ‘AzureRM’
              azureSubscription: ‘Your Azure Subscription(713e8a43-53a9)’
              appType: ‘webAppLinux’
              WebAppName: ‘myappaks’
              packageForLinux: ‘$(System.ArtifactsDirectory)/drop/*.zip’

Pipeline Execution

Click save and run then you can watch the pipeline execute.

Initialize job

I am using my local machine as the agent rather than the Azure-hosted one. If this is something you would like to do then see the following:

Once you have installed the agent on the server you CD to the directory and start the run.exe file.

When you set up your pipeline it will need an agent to execute its associated tasks. An agent is computing infrastructure with installed agent software. You can use a Microsoft hosted or self-hosted approach, as you can see above, I went down the self-hosted route.

You can find the agent details within the main Azure DevOps dashboard under project settings.

Agent pools

Drilling into a pool you will see the relevant detail.

Agent pool details

And the jobs associated with it.

Associated jobs

Most tasks that you execute will need an agent. There is a concept of agentless jobs which can be applied to certain operations such as calling REST API endpoints and Azure functions.

An important element of agents is the idea of parallelism. You have 3 options to select from that are worth knowing about.

Execution plan

  • None – using the same single agent execution of tasks in a serial manner.
  • Multi agent – state x number of agents to execute tasks in parallel.
  • Multi configuration – build multiple configurations in parallel. For example, you could build a Visual C++ app for both debug and release configurations on both x86 and x64 platforms.

Going back to my pipeline it will work through the following steps:

Pipeline steps

The build phase is done and the artifact produced.


Which is then used for deployment to Azure.



Final Thoughts

There are many other pillars/practices of DevOps which are out of scope for this introduction article. These are important topics such as configuration management, release management, IaC (Infrastructure as Code) and continuous testing. As you can appreciate, covering all these areas would need an entire textbook in itself but the aim of this article was an introduction to some capabilities of Azure DevOps.

Find out more about our Application Support and DevOps service, or contact us.


ProGit 2021 2nd edition, Scott Chacon and Ben Straub.

Post Terms: Azure DevOps | CI/CD | DevOps

About the Author

Arun Sirpal, writing here as a freelance blogger, is a four-time former Data Platform MVP, specialising in Microsoft Azure and Database technology. A frequent writer, his articles have been published on SQL Server Central and Microsoft TechNet alongside his own personal website. During 2017/2018 he worked with the Microsoft SQL Server product team on testing the vNext adaptive query processing feature and other Azure product groups. Arun is a member of Microsoft’s Azure Advisors and SQL Advisors groups and frequently talks about Azure SQL Database.

Education, Membership & Awards

Arun graduated from Aston University in 2007 with a BSc (Hon) in Computer Science and Business. He went on to work as an SQL Analyst, SQL DBA and later as a Senior SQL DBA, DBA Team Lead and now Cloud Solution Architect. Alongside his professional progress, Arun became a member of the Professional Association for SQL Server. He became a Microsoft Most Valued Professional (MVP) in November 2017 and has since won it for the fourth time.

You can find Arun online at:

Back To Top
Contact us for a chat