• Setup git repository in VSTS
  • Build Continuous Integration (CI)/Continuous Deployment (CD) pipeline from scratch using VSTS
  • Enable CI
  • Create free web app service on Azure
  • Trigger CD after successful CI
  • End-to-end flow execution


Continuous Integration (CI)/Continuous Deployment (CD) are widely used terms in the DevOps world. If you are new or don’t fully understand the buzzword DevOps then read my article DevOps, What, Why & How. Continuous Integration (CI) and Continuous Delivery(CD) enables and empowers any software delivery team in an organization to continuously deliver value to their end users.


The application which you want to setup CI/CD pipeline for, that project code must be available in a code repository in VSTS (Visual Studio Team Services) read my article Beginning with git using VSTS can be helpful to set up a git repo from scratch using VSTS. Also, an Azure portal account is a must.

Creating a Build Definition

After successful Project and code setup in the git, you will see that your VSTS account will show code repository and a project like as shown below. Here, repository named TestProjects has an ASP.NET MVC application named WebApplication1.

Click on “Set up build” and begin with selecting a template “ASP.NET” as shown in the image below, click Apply. You may want to choose a template which is suitable for your application.

Setting the build tasks

If not already open then open the Tasks tab. By default, build definition name will be <ProjectName>-<BuildTemplateName>-CI (you can change this to something else if you wish to) and Agent queue will be empty, which needs to be set to Hosted (in case of .NET) or Hosted 2017 (in case of .NET Core)  as shown under Process blade in image below.

By default, build is being set up at the master branch on the project you initiated “set up build” from, which was TestProjetcs. You can verify this and change settings if needed using the “Get sources” blade as shown in the image below.

Build Template comes pre-configured with most of the tasks and hence you can review other tasks, but no changed would be required for successful execution from this step onwards (verified for MVC application), however, in your case, you may have to tweak some settings.

Queuing a CI build

To produce deployable artifacts, you need to submit a build of your code. To do so, click on Save & queue or if build definition is saved already then click on Queue which will ask for confirmation to kick-off a build as shown in the image below.

Click on Queue to initiate the process and you will notice that your screen will show that a Build #yyyymmdd.n have been queued.

To track the status of a build you can click on the build number link (as shown in the image above) and if everything was setup correctly then you will see “Build succeeded” as shown in the image below that all the build steps executed successfully.  To explore more about each build step, you can click on a step link shown in the left-pane of the window.

Exploring the Build Artifacts

CI build produces deployable artifacts and those can be seen via clicking on “Artifacts” link shown above Build details.

Setting up the Continuous Integration (CI)

Continuous Integration (CI) is when the code is being built on each check-in and that can be deployed to an environment. To set up this process, navigate to the build definition (click on Edit) and open the “Triggers” tab. By default, continuous integration is Disabled as shown in the image below.

Click on “Enable continuous integration” to enable the CI for TestProjetcs and it will include master branch as the default setting.

Click “Save” to keep the changes to the build definition.  Do not choose “Save and queue”

Continuous Integration (CI) in Action

Ensure that VSTS is open and you have Builds page open. Now switch to the Visual Studio and update the code of WebApplication1 under TestProjects repository

Click on “Commit All” to check-in the changes and push the code to master. Soon after that under the Builds in VSTS, you will notice that another build is kicked off and shows “in progress” status which was triggered by the commit “Title update in About.cshtml”.

After successful build process, you will see “succeeded” status

Setting up the Azure Web App

Before creating a Release definition, an environment needs to be set up for deployment. An azure web app is a perfect choice to host the MVC application.

Login to the azure portal and create a web app “WebApplication1-dev” for dev environment and so other flavors (qa, uat, staging, and production etc.) can be created as needed.


By default, the Web app is created as an S1 (small) pricing tier, but you can create your own service plan and select Free pricing tier. Refer to my article Free Web App Hosting on Azure

After successful Web app creation, it will be available at https://webapplication1-dev.azurewebsites.net/

Setting up the Continuous Delivery (CD)

Continuous Delivery (CD) is a software engineering approach in which teams produce deployable software which can be reliably released to an environment (dev, qa, uat, staging, and production) at any time.

To set up CD click on Build and Releases, then select Releases. Click on “New definition”.

A “New Release Definition” will be created with the template for release as shown in the image below. Change the name of the release to “TestProjects-ASP.NET-CD”, then click on Artifacts and select TestProjects-ASP.NET-CI.  Because, CI build artifacts will be deployed using Release dominion as CD process.

Next, it’s time to setup the Environment, rename it to dev and set values under “Tasks” tab as appropriate.

Creating a Release

After a Release definition has been set up, it’s time to deploy the CI build using the created release, this can be easily achieved by clicking on “Create release” link on the top-right corner.

“Create release” will summarize the setup of showing dev environment and created CI builds to choose from. By default, CI build will automatically kick off the release to the dev environment.

Select the latest build from the list of successful build versions and then click “Create” and notice that “Release-1” has been created.

Click on the link “Release-1” to check the status which will be shown as “IN PROGRESS”

After few seconds Deployment status will be updated to “SUCCEEDED”

Now, if you access the  https://webapplication1-dev.azurewebsites.net.WebApplication1-dev.azurewebsites.net then you will see that web application has been successfully deployed to Azure web app.

Setting up end-to-end automated CI/CD pipeline

In the Release definition click on Artifacts trigger icon (lightning symbol) and enable the continuous deployment trigger and select the branch.

Now, go to Visual Studio and make some changes to the About.cshtml and check-in the code to master branch of WebApplication1 project. Which will then kickoff a CI Build.

Successful CI build will then kick-off the Release for CD to the dev environment.

Upon successful execution of Release, the website will be deployed as shown below (see an updated message on the about.cshtml page).

This point onwards, whenever any code changes will be made using Visual Studio, then a CI build will spin and upon successful build execution, a Release (CD) will be created to deploy the web app.


CI/CD is the most widely used t the rm in industry today and helps in delivering continuous value delivery to the end users. VSTS and Azure offers a lot of great and powerful features to build CI/CD pipeline. This article has shown the process of building CI/CD pipeline from scratch and how to enable various triggers for CI/CD automation during this process.

Seattle Code Camp 2017

I spoke at Seattle Code Camp 2017 on 09/09/2017 and covered two topics.

• AntiPatterns Every Software Development Team Must Know https://lnkd.in/ebEMDBb
• DevOps: What, why and how?

Seattle Code Camp started with a Keynote from Microsoft’s Jeremy Foster and he shared a slide with all Microsoft MVP (Most Valuable Professionals) and FTE (Full Time Employee) who were speaking at 09/09/2017 Seattle Code Camp.

Microsoft got separate printed agenda for MVP and FTE Sessions

Session Details

My 1st Session on AntiPattern was in Room#103 at 11 am -12 pm. I had a brief introduction and begin with the presentation. As already set the expectation with the audience, I kept it very interactive and many participated well to share knowledge and experiences with others.

Some of the attendees even spoke to their friends in the lunch break and recommended them to attend my next session. Some of the attendees returned for the 2nd session for DevOps at 1-2pm and some mentioned that it was the best talk they attended. Well, I thank them for their kind words and patience to provide me an opportunity to share my thoughts with them.

What people said after my sessions

Presentation Slides

Slides are available at https://github.com/vidyavrat/SeattleCodeCamp2017

Contact Me

Please connect with my via
LinkedIn : https://www.linkedin.com/in/vidyavrat/
Twiter : https://twitter.com/dotnetauthor

Send me a message using Contact Me tab on the blog.

Beginning with Git using VSTS

February 9th, 2017 | Posted by Vidya Vrat in ALM / DevOps | VSTS - (0 Comments)


Just like TFVC (Team Foundation Version Control), Git is another Source Version Control and it’s becoming very popular. VSTS (Visual Studio Team Services) supports both TFVC and Git. Let’s assume that you have no project or Repository and wants to begin with Git on VSTS.

Create a New Project

Login to your VSTS account and click on New Project

Fill the information

Click “Create” and you will notice that Project will be Created as shown below.

Clone it in IDE

Click “Clone in Visual Studio”. New Visual Studio IDE will start a dialog like shown below will popup.

Provide the Repository path and click on “Clone”.

Switch to Team explorer and Click on “Create a new project or solution”

When prompted choose the project type. After Project is added successfully you will notice that project is added in Solution Explorer and shows (+) in front of various items and also Team Explorer’s Changes tab shows all the items listed as newly being added.

Commit Changes and Publish

After project being added into Solution Explorer it’s considered as a change to the blank repository/project you created. Hence, this change needs to be added to remote Master branch.

In Team Explorer à Changes, add a comment for check-in and click on “Commit All”

Click “Commit All” and from the next Synchronization Tab, click “Publish”

Now your Git Repository in VSTS should be updated with the code you have pushed-in to it. Refresh your VSTS page and you should be able to see your project code added.