At the job before this one we used to make quite heavy use of VSTS, which is now Azure Devops. I used it a bit, but I am was never the “build” guy. At my current role, I am becoming more and more architecture/devops focussed. I am what one would call a hands on Architect.
Anyway long story short we use Gitlab/Rancher/AWS/Docker where I am now, but I just wanted to keep my toe in with what is going on in Azure, so I plan on getting to know the lay of the land of some of the new tooling
I thought what better way to start with something dead simple, like lets create a new WebApi .NET Core app, and get it deployed to a Azure App Service. This has to be pretty simple to start with right?
So before we start, what I did was sign up for a free tier in Azure, and added all my stuff to a single ResourceGroup in Azure.That way I can just trash it all to keep my costs low. For those that don’t know Azure resource groups are like the uber top level container that all your other services live in.
Ok so lets get started
Step 1 : Create the app
Creating the app for me was as simple as creating a new Web project in Visual Studio 2019, Where I stuck with the standard WebApi project. I literally did not change a thing, I stuck completely with the standard ValuesController, and targeted .NET Core 2.1
Step 2 : Created A GitHub Repo
So now that I have created a pretty useless demo app, I created a GitHub repo, and pushed this code to it
Step 3 : Azure AppService
So I have this small .NET Core 2.1 demo app, so I should be able to run it on Linux. So I sign up the free tier of Azure, then created a new AppService, which looked like these where I was careful to keep to the Dev/Test tier of the size plan
Ok so once that was created I was ready to head over to devops.azure.com
Step 3 : Azure DevOps
So the 1st thing I did was create a new project, lets call it “XXX” for now
From there I picked “GitHub” on the Connect part of the wizard. Next I simply picked my repository from the list, and then it was time to get down with the actual Build side of the Azure DevOps pipeline.
When I last used VSTS it was all UI based, like everything it has all turned to YAML now. So you need to look up the various build tasks to get the available task syntax that you can use. Luckily the basic skeleton was clever enough to give a very hand link to this page : https://docs.microsoft.com/en-gb/azure/devops/pipelines/ecosystems/dotnet-core?view=azure-devops
From there you can grab several of the tasks you might need such as
If you want to see all the available actions for the DotNetCoreCLI@2 task you can look here : https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops, in fact from that link you can use the treeview on the left to find all sorts of tasks to help you live the DevOps pipeline dream
So once I read the docs a bit I ended up with this DevOps Build pipeline configuration
# ASP.NET Core # Build and test ASP.NET Core projects targeting .NET Core. # Add steps that run tests, create a NuGet package, deploy, and more: # https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core trigger: - master pool: vmImage: 'ubuntu-latest' variables: buildConfiguration: 'Release' steps: - task: DotNetCoreCLI@2 displayName: Build inputs: command: build projects: '**/*.csproj' arguments: '--configuration Release' # Update this to match your need - task: DotNetCoreCLI@2 inputs: command: publish projects: '**/*.csproj' publishWebProjects: True arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)' zipAfterPublish: True # this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build. - task: PublishBuildArtifacts@1 inputs: pathtoPublish: '$(Build.ArtifactStagingDirectory)' artifactName: 'AzureDevOpsWebApiTestApp'
I think this is fairly self explanatory.So with this configured, it was time to test the Build. Which worked 1st time YAY.
So with the Build side of the pipeline working, I turned my hand towards the Release side of the pipeline. For me this was as simple as picking this type of release
I filled in the required parameters and ran the Release from the pipeline. It also passed. YAY
I then headed over to my previously created App Service in Azure, grabbed the public url, and gave it a try, and it worked
I have to say I was pleasantly surprised at just how smoothly all of that went.
I will be digging into Azure DevOps a bit more, I would like to see it run some tests, and I would like to setup some private nuget feeds and publish to those and consume from them. This will be the subjects of some future posts no doubt