Let’s create a continuous integration and continuous deployment (CI-CD) with Azure DevOps

I’m about to start a new project and want to have it with a continuous integration (CI) and continuous deployment (CD). I’ve been using VSTS for a while now but didn’t have the chance to try the new pipelines. If you didn’t know VSTS as been rebranded/ redefined as Azure DevOps. Before going in with the real thing I decided to give it a try with a simple project. This post is to relay those first steps.

In a video, please!

I also have a video of this post if you prefer.

Get Started

Let’s start by creating our Azure DevOps project. Navigate to Dev.Azure.com and if you don’t already have an account create one it’s free! Once you are logged in, create a new project by clicking the New project blue button in the top right corner.

You will need to provide a unique name and a few simple information.

The Application

First thing first, we need an application. For this post, I will be using a simple Asp.Net Core site. For the repository, we have options. AzureDevOps (ADOps) support many repositories: GitHub, Bitbucket, private Git and its own. Because the project I’ve created is public I decided to keep the code at the same place as everything else.

From the left menu, select Repos. From here if the code already exists just add a remote repository, or clone the empty one on your local machine, the usual. Create and add your code to that repository.

The next step is to create a placeholder for our CD pipeline. We will create an empty shell of a web application in Azure with these three Azure CLI commands. You can execute them locally or from the Cloud Shell. (Don’t forget to validate that you are in the good subscription)

az group create --name simplegroup --location eastus

az appservice plan create --name simpleplan --resource-group simplegroup --sku FREE

az webapp create --name simplefrankweb --resource-group simplegroup --plan simpleplan

The first command will create a Resource group. Then inside of this group, we create a service plan, and finally, we create a webapp to the mix.

Continuous Integration

The goal is to have the code to get to compile at every commit. From the left menubar, select Pipelines, and click the create new button. The first step is to identify where our code is, as you can see Azure DevOps is flexible and accept code from outside.

Select the exact repository.

This third step displays the YAML code that defines your pipeline. At this point, the file is not complete, but it’s enough to build, we will come back to it later. Click the Add button to add the azure-pipelines.yml file at the root level of your repository.

The build pipeline is ready, click the Run button to execute it for the first time. Now at every commit, the build will be triggered. To see the status of your build just on to into the build section from the left menubar.

Continuous Deployment

Great, our code gets to compile at every commit. It would be nice if the code could also be automatically deployed to our dev environment. To achieve that we need to create a Release Pipeline. And our pipeline will need artifacts. We will edit the azure-pipelines.yml to add two new tasks. You can do this directly in the online repository or just from your local machine; remember the file is at the root. Add these commands:

- task: DotNetCoreCLI@2
  displayName: 'dotnet publish $(buildConfiguration)'
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

- task: PublishBuildArtifacts@1
  displayName: 'publish artifacts'

Those two tasks are to publish our application (package it), and make it available in our Artifact folder. To learn more about the type of command available and see example have a look the excellent documentation at: https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core. Once you are done, save and commit (and push if it was local).

From the left menubar, click on e the Pipeles, select Release, and client the New Release blue button. Select the template that matches your application. For this post Azure App Service deployment is the one we need.

The next thing to will be to rename the environment for something else than Stage 1, I named mine “to Azure” but it could be dev, prod or anything that make sense for you. Click on the Add an Artifact button.

You will now specify to the pipeline were to pick the artifacts it will deploy. In this case, we want the “output” of our latest build. And I renamed the Source alias as Drop.

To get our continuous deployment (CD) we need to enable that trigger by clicking on the little lightning bolt and enabled it.

The last step to configure the Release pipeline is to specify a destination. By clicking on the “1 job, 1 task” in the middle of the screen (with the little red exclamation point in a circle), that will open the window where we will do that.

Select the subscription you would like to use, and then click on the Authaurize button on the right. Once it's done go change the App Service Name. Click on it and wait 2-3 seconds you should see the app we created with our Azure CLI display. Select it, and voila!

Now add a ReadMe.md file by checking out the code on your local machine or directly in Azure DevOps. Grab a badge from the build and/or release and copy paste it in the ReadMe. To get the code snippet of your badge, go to your build/ release definition, and click the ellipse button. Select Status badge and copy the snippet that matches your destination file (in our case the Markdown).

Now when you go to the Overview page, you will have a nice badge that informed you. It also works on any web page just use the HTML snippet instead.