POV: Your dev team is hacking away in a regular Hack Day and you realise they could use a simple DevOps pipeline to deliver the product of their efforts straight to Azure. In this blog post, I will show you how to do that.

Where to start

The code may be hosted on GitHub, but the journey starts in our Azure DevOps organisation. Hit + New Project and fill out the required fields.

Once in the project, on the left pane navigate to Pipelines and hit the Create Pipeline button.

On the Connect tab, we choose GitHub as that's where our code is. Let's assume our Azure DevOps organisation has not been previously connected with GitHub.
On the Select a repository tab, go with You may also select a specific connection.
On the next screen, press Install the GitHub App. Log in and select as appropriate to give access to either All repositories or Only select repositories.

Back on the Select a repository tab, you should now be able to see the repository listed.
On the Configure tab, select ASP.NET Core.
The Review tab opens a YAML editor with some defaults based on what we chose in the previous tab. Delete all of the content - we will start from scratch.

YAML

Our YAML file starts with a trigger. This refers to the name of the branch that will trigger a pipeline run.

trigger:
- main

This specifies the image with the environment we want the agent to execute the pipeline on:

pool:
  vmImage: ubuntu-latest

Next, we open the steps part of the script and add the first task. You can either type this in or find the Use .NET Core task in the assistant on the right and add it from there.

steps:
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    useGlobalJson: true

The next two commands, defined as scripts to run, are pretty much a boilerplate for the SAFE Template projects we at Compositional IT like to work with. They will be executed (sequentially) right after the code is checked out from the repo/branch. dotnet tool restore restores tools defined in .config/dev-tools.json and dotnet paket restore downloads/restores dependencies. These commands would normally be followed by a dotnet run runtests, but we'll be skipping that here.

- script: dotnet tool restore
  displayName: Restore dotnet local tools
- script: dotnet paket restore
  displayName: Download nuget packages

Add another task:

- task: AzureCLI@2
  inputs:
    azureSubscription: 'Microsoft Azure (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)'
    scriptType: 'pscore'
    scriptLocation: 'inlineScript'
    inlineScript: 'dotnet run azure'

This runs another command: dotnet run azure. The reason we didn't bunch it up with the previous two is that this command executes an ARM Template deployment against our Azure subscription, and as such it needs to be wrapped in a task that executes it in an Azure CLI context that takes care of the authentication concern before the deployment script is executed. You will need to add this step from the assistant. Find the Azure CLI task and fill in the fields. The Azure Resource Manager connection will populate with predefined service connections or azure subscriptions your account has access to. Upon selecting a subscription, you will need to press the Authorize button.

Variables

We haven't needed any for this simple script, but this is where we'd put any secrets we want the pipeline to have access to during a run. Obviously, these are not commited to the repo and are only saved with the pipeline definition in Azure DevOps.

The Complete YAML Script

trigger:
- main

pool:
  vmImage: ubuntu-latest

steps:
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    useGlobalJson: true

- script: dotnet tool restore
  displayName: Restore dotnet local tools
- script: dotnet paket restore
  displayName: Download nuget packages

- task: AzureCLI@2
  inputs:
    azureSubscription: 'Microsoft Azure (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)'
    scriptType: 'pscore'
    scriptLocation: 'inlineScript'
    inlineScript: 'dotnet run azure'

The First Run

After adding the last step, hit Save. This will commit the azure-pipelines.yml to the repo. As this is a new commit on the main branch, it will also trigger a pipeline run. In the Azure DevOps UI, navigate to Pipelines, select the one we just created and observe the run.

More on Authorisation

If your pipeline fails with "There was a resource authorization issue..." error, you need to visit Project settings | Service connections and grant necessary permission (this is a one-off).

Conclusion

There's a lot more to Azure Pipelines than what we've shown here. Your regular production pipeline can and most likely will:

run tests and publish test results
comprise multiple stages that deploy to different environments
publish artifacts in one stage to make them available to the next
provision additional resources
and all of that will definitely involve the use of pipeline variables!

A DevOps Pipeline From Scratch