CI/CD DevOps pipeline for microservices using VSTS –part 3

Somak Das
Somak Das
Apr 20, 2017 · 6 min read

In the previous part we saw how to create the build pipeline for our .NET core webapi. So just for a quick recap we were able to create build definition that builds our .NET core webapi, creates docker image of the api and finally pushes the image to docker hub.

In this part we will see how to run the docker image of the .NET core webapi and run it inside the kubernetes cluster. But we will achieve that using VSTS Release management.

To know more about Release Management in VSTS please check here.

Now before we move on to creating the release definition, we need to add one more build step.

Step 1: Add build step Copy and publish Artifact

First we will go to the build definition that we created in the previous post. Click on edit and add one build step.

From the gallery select the Copy and publish artifact task. This will copy source files and drop it in the server as build artifact.

In the copy root we select the Kubernetes folder from the source repository, and in the contents we specify ** , which means the task will copy all files in side the root folder and its sub folders.

For more info on how to use the copy and publish task please visit here.

But before proceeding further, we need to add one more file in the repository for the Release process.

Remember the kubectl.exe file which we used to connect to our kubernetes cluster in “Containerizing a .Net core application using Docker, ACS and kubernetes — Part 3”?

Copy that kubectl.exe and paste it inside the Kubernetes folder where we kept our .YAML file for the kubernetes deployment. Add the kubectl.exe file to your git repo by :

open command promptcd <your git repo>git add — allgit commit -m “added kubectl binary”git push

Note: I assume at this point this is the only possible change in the repository. That is why we did git add — all , else specify the file that you would like to add in the repository.

For a reference to the code base that I used for this example and to see the folder structure and the kubectl.exe file please check here.

So after we have pushed the file to our repository and saved the build definition, we will go ahead and queue a new build to test if its working fine.

Now we will move forward with our Release definition.

Step 2: Create Release definition

Once a build has succeeded, we will now move to Release. In this demo we will do a basic Release management, by simply running the docker image that we pushed to our kubernetes cluster.

We will not do anything fancy like deploying to different environments like Dev , QA , Prod, etc. We will try to make things simple.

For Release, go to the Release tab from Build + Release, and click on + icon to crate release definition.


We will start with an empty release template.

Select your team project and the build definition that you have just created and click on Create.

Note: You can choose Continuous deployment to automate the release process once a build succeeds.

Step 3: Add release steps

We will only need one step for running into our kubernetes cluster. But for that we will visit the marketplace once more for another task installation.

From the marketplace download the Kubernetes extension.

This extension will allow you to run any kubectl command in a running kubernets cluster.

Now in the new Release that we had created earlier, we will rename the default environment, that is created by default as prod, you can name it anything you want. But as I mentioned earlier I am not going to add additional environment and keep this demo simple to a single environment.

Next click on Add tasks, to add Release task, which in our case is the kubectl apply task that we downloaded from the marketplace.

Apply task

This task has three main arguments as shown in the picture below.

Task details

1st is the k8s end point i.e the endpoint to our running kubernetes cluster.

To add connection to kubernetes endpoint we will add connection to our kubernetes cluster.

Click on Add to add a new connection.

Give any name to your connection, server URL is the url to our cluster. You will get the value from the azure portal. Go to the container service resource select your container service that you have created and in the overview select the Master FQDN as the Server URL.

Last parameter here is the kubeconfig which is the content of the .config file which gets downloaded in the .kube directory once you connect to the cluster with your credentials. It generally gets downloaded by default in The config file will get downloaded in your local machine at %USERPROFILE%/.kube/config

To connect to cluster check my previous post here.

Ok so now that we have create our kubernents connection lets proceed with the other parameters in the release task.

The next two parameters are the path to the YAML file i.e the kubrenetes object file and the kubectl.exe file.

Remember our last step in the build defenition that we created? So we will get those file from the artifact named drop that we created.

Once 1 build has been done successfully, click on browse button and you will be able to see the two files inside the drop directory.

So we need to select the path of these two files.

*Note: You will be able to see these files only if you have successfully done a build once.

So save the release defenition by giving it a name of your choise. Now we are ready to queue a release and run the docker images that we build inside our kubernets cluster.

To queue a new release, click on new release and fill in the details.

Give a release description of your release, select the build number(by default it will be the latest) and for Automated Deployment select automated deployment after release creation option.

This will automatically trigger the release to this environment when you create a release. Else you can select manual which will ask for your permission before triggering the release to this environment.

To know more about release management in VSTS see here.

Once the release succeed, you will be able to see the objects that we have created inside the kubernetes cluster.

So this was the very basic DevOps pipeline for our ASP.NET core microservice. Please feel free to ask any question or share your thoughts in the comment section below. And if this post was helpful please recommend this to your friends.

Till then keep exploring and keep coding :)

Somak Das

Written by

Somak Das

Enthusiastic full stack developer focusing on cloud architecture, microservices, DevOps and automation.

More From Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade