VSTS CI Build for Dockerized .net Core 2.1 multi-container app

Background

This is 2nd part of the series on Continuous Deployment of Multi-Container app in Azure using VSTS and Docker. In the first part I laid out the broad idea of what I intend to do as part of this series. Lets get started with the first step of creating the Continuous Integration build definition. Setting up the CI build involves multiple steps right from choosing the build server, getting the source code from the source code repository, running unit test, ensuring code quality by running static code analysis, producing the build artefacts etc. It would be difficult to cover all those topics in single post. I will focus on initial step of connecting the build server to the source code and update the source code on each checkin.

Create New VSTS Build

As mentioned in the pre-requisites in the first part of this series, I assume you have a valid VSTS account. Login to your account and you will be presented with the screen similar to what is shown below

Click on the new project option to create a new VSTS project. You will be requested to provide minimal settings to start new project. Project name and Description are self explanatory. When it comes to version control you can chose from Git or Team Foundation Version Control.

I have my Github repository which I will be linking shortly. So I will go and pick Git. Last step is to chose the process template. VSTS provides Agile, CMMI or Scrum as the available options.

I will go with the default of Agile template. Based on your team needs you might want to chose other template. Based on the work item template selected, VSTS will provide additional features for the application lifecycle management. For example, when I chose Agile, I will be give default Sprint and Iteration planning templates which can be helpful while working in teams.

With these basic information VSTS will create a project and whole set of related items for us. After successful completion of the project you should be presented with a welcome screen for newly created project

You can start with a blank repository or push an existing repository to VSTS. You also have options to import source code from various supported providers like Bitbucket, Github, Subversion etc. In our case I do not wish to duplicate the source code between Github and VSTS. I am going to continue using Github as my source code repository and use VSTS purely for the purpose of build and release management.

Setup Build

Click on the Set up Build hyperlink. This will navigate us to the screen where we can define a new build. Based on the type of technology and type of project VSTS provides prebuilt templates. I could have chosen ASP.Net Core project, but I preferred to use the Empty template.

Similar to the project definition, build definition also needs some basic information to get started with.

Provide some unique name for the build. We can choose from 4 different types of queues

• Hosted
• Hosted Linux Preview
• Hosted macOS Preview
• Hosted VS2017

We will choose the Hosted Linux Preview option. At this point of time we need to decide what are the different steps our build is going to perform. First of all we need the source code to be available on the build server. Click the Get Sources section to establish the connection from one of the available source

I selected GitHub and provide a meaningful name (GitHub DotNet-2017 Connection). I opted to authorize with OAuth and was presented with a popup to provide the credentials to connect to GitHub account. Once successfully I will have access to all the GitHub repositories.

I selected dotnet-2017 as the repository. With these configurations we are ready to go. Lets test that we are in fact able to pull the source code hosted in public GitHub repo to the build server. Click on the Save & Queue option to trigger the first build. You will get a hyperlink to the build number, click that to go to the build details. If everything was configured correctly, you should see the log of what happens during the process

The build is successful and we can see the details of each phase if we wish to go into the details. This proves that our connection between VSTS and GitHub is working fine. The last part remaining is to trigger the build automatically anytime there is change to the source code in GitHub. That is pretty easy. Go back to the build definition click on edit option to edit it.

Click the Triggers to enable CI trigger. Default is turned off because of which the changes to source control are not automatically built. Enable this setting and we will have automatic build triggered for every change. I like to enable one more option to Batch the changes if there is already build in progress. This will ensure that any changes checked in while another build is in progress are batched together instead of running individual builds for each change. Save the changes. To test this feature you will need to checkin some changes to GitHub. That is an exercise for you to test your knowledge so far.

Conclusion

This was the stepping stone to get our journey stated with VSTS and automated build. We managed to integrate GitHub and VSTS. With the base set nicely we will be cruising along in the future posts of the series. Microsoft has managed to replicate most of the features from on prem Visual Studio Team Foundation server to the online offering. With minimal efforts we can start building CI and CD pipelines. Feel free to explore other features related to CI build. Until next time code with passion and strive for excellence.

Share: