Creating A CI/CD Pipeline Using VSTS

In this article, we are going to learn about continuous integration and continuous deployment using VSTS.

For the purpose of this demo, we will be using on-premise "Team Foundation Server 2015 Update 3".But we can implement the same on Azure also.

Before going into the details about how we can achieve continuous integration and continuous deployment using VSTS, we will first look into what is continuous integration and deployment.

What is continuous Integration and deployment? 

Continous integration and Continous deployment are the buzzwords in the DevOps world.

So what is continuous integration?

According to Microsoft Docs (Click here), "Continous integration is the process of automating build and testing of the code everytime the developer commits the code to the source control". Whenever the developer commits the code to the repository a trigger is fired and the latest code is taken from the source control and a build and test is triggered. The main benefit of it is that it reduces the time and cost spent on the integration of the code. The developer commits his/her piece of code along with the unit tests and as soon as the code is committed, an automated build happens and unit test is run. If there are any issues in the build or test cases, the build fails and are automatically reported to the team.

What is continuous deployment?

As the name suggests continuous deployment is the process of automatically deploying the output of the builds (packages/components) to the respective environments. What needs to be deployed and when it needs to be deployed can be configured. The process of continuous deployment speeds up the rolling up of a new feature, bug fixes, etc.

Now, we have the basic idea of continuous integration and continuous deployment, so we will see how we will implement it using VSTS.

First, we will see how to create a build definition and manually trigger a build and in the later part of the article, we will configure the build to be automatic.

Creating Build Definition in VSTS

To create build definitions, go to the project dashboard and click “Build” link. This will open up build page containing all build definitions. 

 

 

 Now, click on “+” to add a new build definition. A “Create new build definition” will open up containing sample template. Select Visual Studio template and click “Next” button.

 

A “Settings” page will open up. Select repository source from the available options and click “Create” button.

 

A new build definition will be created as shown below.

 

This build definition will contain various tasks. We can also create a new task by clicking “+ Add build step” button. Click on “Save” button to add the build definition name.

 

For the purpose of the demo, I am removing Test task from the build definition by just clicking the cross button that appears when we hover a task.

In the “Copy Files” task by default, we have contents as “**\bin\$(BuildConfiguration)\**”.

Replace it with “**\*.*” so that everything will be copied.

In “Publish Build Artifacts” task select “Artifact Type” as File share and in path provide the path to shared drive.

 

Now queue the build by clicking “Queue build” as shown in the above screenshot.

“Queue Build” dialog will open, click “Ok” button.

 

 

Once the build is queued, it will be picked by an Agent available in “Agent Pool”. 

 

 

All the build steps will be shown as below.

 

We can see the individual build step by clicking the task as shown below. In the below screen shot we can see the drop location of publish artifact

Create a release definition

Now we will create a release definition by clicking “Release” link.

 

 

Click “+” button to create a new release definition. Select from the available deployment templates. For the purposes of this demo I am selecting “Empty template” and click “Ok” button.

Similarly we will create multiple environments as shown in below screen shot.

 

Click on the ellipses in Dev and select “Assign approvers”

 

 

In the Deployment condition in Trigger select “After release creation” radio button and click “Ok” button.

 

Now we will add a task to copy the files from drop location during release to the location.

Select Environment and click “Add tasks”. Add tasks window will open select “Windows Machine File Copy” task.

 

 

We will link the release to build definition by selecting “Link to a build definition” link.

 

In Copy task provide the source path as drop path for build and destination path along with admin user and password for destination machine. Below is the sample path for source.

\\localhost\DevopsBuild\TFSBuildDefinition\$(Build.BuildNumber)/drop/TFSAutoBuild

 

Save the release definition and select “Create Release”.

 

Select the build version and click “Create” button. This will create the manual release.

 

Go to the release definition and select release version to view detailed progress of the release.

 

 

Now, we are done with manual build and deployment. We will now modify our build definition for continuous integration.

Go to build definition and click “Edit”. In the “Triggers” select the “Continuous integration (CI)” checkbox.

With this checkbox enabled, whenever a developer checks in the code the build with automatically start and on success it will drop the artifacts to the drop location.

 

Similarly, we need to implement continuous deployment by changing the release definition. Edit release definition and select “Continuous Deployment” along with build definition.

 

Now, we are done with continuous build and continuous deployment. Whenever a developer checks in to a source control, an automated build will be triggered. On successfull build, an automated deployment will be triggered.