Continuous Integration Between Github and VSTS

Build

In the first post, I tried to explain the CI and CD concept means. And now I’ll try to explain basic CI/CD operations over a simple open source .net library. We’ll integrate a GitHub repository to VSTS and create a build and a release definitions in VSTS.

Visual Studio Team Services (VSTS) is a “software as a service” offering by Microsoft (previously called as “Visual Studio Online”). It’s actually a Team Foundation Server (TFS) that available on the Internet. Microsoft offers Basic, Professional, and Advanced subscription plans for VSTS. The Basic plan is free of charge for up to five users which I use in this post. First, create a free VSTS account from https://www.visualstudio.com/team-services/. After you log in, click “New Project” button. Name your project and choose version control and development process template (It doesn’t matter you choose). Then click “Create”.

VSTS New Project

After a while, It creates the project and shows you the front page of the new empty project. Select “Build & Release” from the menu and click “Build”. Click “+ New Definition” button.

“Create new build definition” dialog opens. Select Github for the repository source. Select “continuous integration” box which allows the build will be automatically triggered when the GitHub repo is changed.

Select “Hosted” for agent queue. This queue hosted by the VSTS and It builds your definition on the cloud. It has also four hours (max. duration of 30 minutes per build or deployment) per month run-time limitation on basic subscription.

VSTS New Build Definition

If you want to run your build on your computer or in-premise server. You have to download, install and register a new agent to a new agent queue. And also you have to install some prerequisite applications according to your build definition. (ex. Visual Studio, .net Framework etc.). For more information about hosted and private agents please see https://www.visualstudio.com/en-us/docs/build/concepts/agents/agents

And finally, leave “\” for the build definitions folder. You can make definitions folders and keep all definitions organized in them. Click “Create” and then a default build definitions will be created.

You see a red exclamation placed over the repository tab on the screen and save button is not available. This is normal because we need a GitHub repo connection for the build definition.

Select “Repository” tab then click “Manage” button placed the right side of the grayed connection selection. “Services” window opens, click “New Service Endpoint” on the left side and select “Github” from the pop-up menu. Click “Authorize” and log in with your Github account. Then select “OK”.

Return back to previous repository tab and click refresh icon near manage button on the connection row. Your new added Github account appears on the connection row and other gray boxes fill with your Github repos and branches. Select the repo and its branch you want to build. Select “false” for “Clean” selection for speed up the build process. If you want to clean the build folder. You could select “true” for “Clean” and relevant options for “Clean options” selections.

Click “Save” and name this build definition.

VSTS Build Definition

This is a default build definition and It’s usually enough for most projects. You could change steps and also add new steps with “Add build step…” button. The build agent will perform these steps on the source one by one.

In default layout, there are sources and an artifacts folders in the agent’s working folder. There is an invisible “Get Sources” step at the top of these steps that downloads whole repo to agent’s working folder first. And then after these building steps (nuget restore, build, copy etc.), all the build outputs (artifacts) will be placed on the artifacts folder. The last step in the default layout is “Publish (upload) Artifacts” which uploads these artifacts to VSTS for future use in the Release / CD operation.

Change these steps according to your needs. For example, I need a nuget package must be created after compile step. I add “Nuget Packager” step after “Test Assemblies” step. Then I remove a couple of steps.

Now select “Queue new build” button. A new build order is set and start to run in a couple of seconds. (sometimes couple of minutes :confused:)

VSTS Build

After build completed, if there is a thing that does not go well, you can check build logs and the reason for the problem. If all the steps completed successfully, you can check the artifacts from artifacts section on the build page.

VSTS Build Artifacts

Now with VSTS, we downloaded the source from a GitHub repo, built this source, tested outputs and created a package. And finally, we uploaded this package as an artifact to VSTS.

For to test the continuous integration, you could simply make a change to Github repo. This will trigger the build in a couple of seconds.

In the next post, I’ll try to explain CD operations in VSTS. We will download these build artifacts from VSTS and publish them to nuget.


       


alatas.github.io    github pages, hyde theme, liquid, jekyll { paginate, gist, sitemap, seo-tag, feed, jemoji }