VSTS DevOps - Quick Guide To Setup VSTS Continuous Integration

In recent times, there has been a new wave in the software industry. Techies have already built a lot of technologies, frameworks, programming languages, and platforms, so the next big question is:

HOW CAN WE REDUCE THE GO TO MARKET TIME?

Cloud on-boarding in the past few years has really revolutionized the industry and also given a concrete platform to answer this question. In order to push code from developers' machines to cloud/on-prem infrastructure, there are a lot of tools and platforms available in the market such as Jenkins, Octopus Deploy, TeamCity, VSTS etc. Being a developer, what I look for is which tool/ technique can get the job done with efficiency, reliability and minimum effort. When we are on client projects we have limited time, and no matter the developer he or she will appreciate if most of their time is spent on business requirements, understanding, development, and testing, rather than configuring build/release tools.

I have tried my hands on a few of the above-listed tools, I would say each of them, be it Jenkins/Octopus Deploy/TeamCity/VSTS, have their own strengths and weaknesses. In my opinion, VSTS has all the tools and features which can  go to market for any project/technology with the least effort.

I already assume that you have a VSTS account, if not it's simple. Go to VSTS and create a new account. You will need a Hotmail/Outlook account for that.

 

Once finished you will have a VSTS collection created for you, with MyFirstProject as default project. We will create a new project by the name VSTS DevOps using New Project button

Below is a quick guide to how we can configure a project for VSTS Continuous Integration, for demo purposes I am using ASP.NET MVC project. But if you are building project in any technology/ platform such as .NET/Java/Mobile/Docker etc VSTS has full support for each.

1. Let us create a simple vanilla ASP.NET MVC project. Build and run it. I have made some text changes in the default template of Index page as below.
   
   
   
   
   
    
   
   
2. Connect Visual Studio to VSTS using Team Explorer.
   
   




 
3. Go to solution control explorer and right click in the right pane and select Add Items to Folder.
   
   
    
4. Once the code is checked in from VS, you can navigate to VSTS and select code Menu item from breadcrumb.
   
   
5. Go to Build tab now and click New definition.
   
   
6. Select code source location and folder path to project folder. You have a wide range of options to select source code location; i.e. GitHub, GitHub Enterprise, Subversion, Bitbucket and External Git. I have already posted a blog on how you can use Github source control to integrate with VSTS DevOps
   
   
    
7. Now we will select Build Template. VSTS out of the box gives you a long list of ready-made templates which you can use off the shelf to configure VSTS CI, as in the image below. In our case, we will select an Empty template and configure it for our project.
   
   
    
8. Let's add a few tasks to our definition. Just like any .Net project first we need Nuget packages, then Build solution using MSBuild and finally on success, the artifacts are pushed to either debug or release folder in the bin. Similarly, we will add NuGet Task, VS Build task, Copy Build Files task and Publish Files task to build a simple template for building and packaging of our MVC project.
   
   
   
   
   
    
9. Let's now configure each of the tasks selected as below.
   
   
   
   
   
   
   
   
   
    
10. As in step 9, we have already configured all the tasks, the next step is to test if all the configuration works as desired. If they do, at the end of the build we will have a successful result. In the build result, we will have an artifact tab with deployable artifacts.
    
    
    
    
    
    
    
     
11. Below is the screenshot for build logs pushed in real-time to the browser. This is really helpful as it gives details about what is happening behind the scene and what task is currently in execution.
    
    
     
12. In our first build, NuGet restores failed.
    
    
     
13. What it states is it is unable to restore a few of the packages from NuGet repo. A quick workaround is when you check the code in step 3, check in all the Included and Excluded files as below.
    
    
     
14. Next build request succeeds.
    
    
     
15. Now, if we navigate to Artifacts tab we will get Download and Explore option. If we explore we can see the artifacts packaged as zipping,
    
    

With this, we have achieved successful Continuous Integration implementation. If you want to push the envelope a bit more the next step is implementing deployment. Including deployment in CI can be a valid scenario but is not always preferred. It is valid for cases where you do not need any workflow for release or you do not have many controlled release environments. In order to implement release it's simple -- we just need to add a release task, for this demo we will take the MVC Website artifacts and deploy in Azure web app.

1. First, you need to add a new app service to Azure, for the demo we are adding VSTSDevOpsCI. If you do not have an account it is simple just create new Azure account (please use the same Hotmail/Outlook account details you created above, this will make things easy later), you will get $250 worth of credits to your subscription as a complimentary first-month benefit. Add a new Web App.
   
   
    
2. Next, you need to link your Azure account to VSTS. In Azure subscription item under Azure, App Service Deploy task, click Manage. Click new Service endpoint and select Azure Resource Manager.
   
   
    
3. Once your Azure account is connected to VSTS, you can access all resources in your Azure subscription using the server endpoint created in VSTS.
   
   
4. Add a new Azure App Service task to build definition.
   
    
5. Let's configure the task. We have selected the same endpoint as created in step 2. This populate VSTSDevOpsCI app service on the pick list. Also, the package folder path is
   $(System.DefaultWorkingDirectory): Refers current build directory path on the server
   **: Refers to checking all folders until you find DevOpsWeb.zip
   
   

Let try to queue a new build. If all goes well will have the MVC website deployed to VSTSDevOpsCI app service after CI is complete.

You can check the URL the website is running on Azure.

In order to do a quick test, let's make some changes in our VS code and check in again. It should update the website in Azure.

Not there yet. ... 

In order to accomplish the above release per the check-in requirement, we need to update a simple setting in build definition as below. Go to trigger tab and check Enable continuous integration checkbox.

Let's update the code in VS and check-in.

Build gets queued as soon as check-in is complete.

As below,  Build number 12 is successful.

So, lets get an Azure website to check if the changes are reflected. Yes they are: the heading has Version 1.0 added.

Summary

As you can see, it's very simple to configure CI in VSTS and if your project has a simple release plan then the release can be integrated into the same build definition. Now if you don't want to deploy your artifacts in Azure, but instead on AWS or OnPrem server, there is a wide range of solutions to this problem. You can download artifacts using VSTS APIs and deploy to the desired environment. A better approach is you can get a copy of VSTS build agent. The build agent setup for your collection can be download for the VSTS portal. Install the agent on one of your AWS/ OnPrem servers and then instead of using Azure as a deployment point you can use File transfer task or Powershell task to deploy in the desired IIS folder. The avenues are endless -- VSTS is very mature now and the VSTS team has already addressed most of the regular CICD challenges experienced by any project team. If you don't get an off the shelf task for your requirement you always have PowerShell/batch task options to build one.