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.
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:
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.
CI / CD
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.
YAML Pipeline
I then use YAML to build the pipeline.
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).
# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4
trigger:
– master
stages:
– stage: Build
jobs:
– job: Build
pool:
vmImage: ‘vs2017-win2016’
variables:
solution: ‘**/*.sln’
buildPlatform: ‘Any CPU’
buildConfiguration: ‘Release’
steps:
– task: [email protected]
– task: [email protected]
inputs:
restoreSolution: ‘$(solution)’
– task: [email protected]
inputs:
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’
inputs:
SourceFolder: ‘$(build.sourcesdirectory)’
Contents: ‘**/*.json’
TargetFolder: ‘$(build.artifactstagingdirectory)’
– task: [email protected]
displayName: ‘Publish Artifact’
inputs:
PathtoPublish: ‘$(build.artifactstagingdirectory)’
– task: [email protected]
inputs:
PathtoPublish: ‘$(Build.ArtifactStagingDirectory)’
ArtifactName: ‘drop’
publishLocation: ‘Container’
– stage: Deploy
jobs:
– job: Deploy
pool:
vmImage: ‘vs2017-win2016’
steps:
– task: [email protected]
inputs:
buildType: ‘current’
downloadType: ‘single’
downloadPath: ‘$(System.ArtifactsDirectory)’
artifactName: ‘drop’
– task: [email protected]
inputs:
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.
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: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops
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.
Drilling into a pool you will see the relevant detail.
And the jobs associated with it.
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.
- 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:
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.
References
ProGit 2021 2nd edition, Scott Chacon and Ben Straub.
https://docs.microsoft.com/en-us/azure/devops/user-guide/what-is-azure-devops?view=azure-devops
