CI/CD through Azure DevOps

In this blog I will explain how Azure DevOps helps Continuous Integration and Continuous Deployment.

Introduction
 
Continuous Integration and Continuous Deployment (CI/CD) is part of the modern software development life cycle. Gone are the days when "application building & deployment" used to be a tedious manual process. Now you have the option to make it automated with just few clicks.
 
There are many CI/CD tools available in the market. They each have their own selling point/trade-offs.
 
In this article, I will be focusing on one of the popular tools called VSTS or “Azure DevOps”. Some of the reasons I chose this are:
 
1- It has cloud-based Git repository, and supports open source Git repositories as well
2- Easily configurable Build and Release pipeline, irrespective of languages
3- Intuitive UI, I personally felt it guides you through the steps
 
Let’s get through some actions to understand Azure DevOps capabilities.
 
First things first, I created one free account in "Azure DevOps" to demonstrate CI/CD. I will be publishing my application in Azure so I have also signed up in Azure for a trial account.
 
My application, an ASP.NET core 2.0 RESTful WebAPI that I developed few days before writing this article, was hosted in a GitHub repository at that time.
 
Though Azure DevOps has the option to integrate with GitHub,  I will be using DevOps repository (for code) and CI/CD utility, to keep things nice and simple. Apart from that it is a good opportunity to demonstrate how we can commit our code to two Gits.
 
Implementation 
 
To begin with, go to Azure Devops and create a Project.
 
My RESTful application name is BackendAPI so I prefer to keep the same name for the project. Note I choose for it to be a private repo because I will not be sharing this code.
 
 
 
 
A successful project creation ends up with the following screen. This indicates it is ready for you to work.
 
 
 
Now I would like to upload my code to Azure DevOps. For that I need to verify if there are any pending changes to commit (to my GitHub). 
 
For that I went to the path where the project is located and used “git status” command. The status “nothing to commit” confirms there are no changes remaining to be committed. 
 
 
 
Then go to Azure DevOps “Repo” menu and you will see a couple of commands. One of them shows how to push into Azure repository. So I copied the command to push changes.
 
 
But there is an issue with my situation. As I mentioned earlier my code is linked to “GitHub” already so I got an error saying the “remote origin already exists”. This means I cannot keep the same origin name.
 
So instead of “add origin”, I changed it to “add azureorigin”. Everything else remains the same.
 
 
 
Once the command's execution completes I can see it in the repo. Great!!! 
 
So I have got the code repo to work with. 
 
 
 
 

Now this is the time to create a build pipeline. This also means any commit to Azure repo will trigger a new build.

So in menu “Pipelines”->"Builds", I choose Azure Repos to create a new build pipe line.
 
 
 
 I selected an available repository, in this case only one, “BackendAPI”.
 
 
 
The next step is choosing the template. I chose ASP.NET core, as my application is ASP.NET core API.
 
 
 
Once you finish this step, you will see a new file, “azure-piplelines.yml” has been added. This file contains necessary information for building application.
 
No need to change anything in this instance so I will go ahead to choose “commit” option and click “save and run”.
 
 
 
This will start a new build. After a successful build this is how it looks like. 
 
 
 
You will also be able to see the build# and when it was triggered. Awesome!!! 
 
So our build pipeline is ready and working. 
 
 
 

The next step is the application release pipeline.

Releasing involves 2 steps.

Step 1- Copy the latest binaries to “artifact” and then
Step 2- Use the “artifact” to publish it in the desired environment
 
For this I will pull “azure-pipelines.yml” in my local machine to add settings to publish.
 
Publishing setting starts from the line with command “- task DotNetCoreCLI@2”.
 
Note I prefer to update this file locally, however you don't need to. Also the setting “publishWebProjects" is kept "False”, i.e. the application I am publishing is not a web application, it is a WebAPI.
 
 
 
 

Anyway, change and commit this file and this should trigger a new build. If it does it indicates build pipeline is working as expected.