Workshop Continuous Delivery with VSTS into Azure

Team Foundation Server is long past the tool just for .NET developers. What are the possibilities and how to connect it to your favorite systems and tools you have been accustomed to be working with. In this post we will build a Continous Delivery pipeline  from either TFVC or Git with or without Jenkins via Infrastructure as code to a instant  Azure VM. Fully traceable tests, approval steps and linked workitems in an audit able CD pipeline.

This post will be the guide line for lab that belongs with the presentation given at DevoTeam on February 7th 2017 and is written for entry level developers and operations. Try to resolve each step by talking with each other and  when you can’t figure it out click the link for explanation and help.

Due to many requests this post will stay up after the workshop and I will continue to make corrections, improvements and additions. Any ideas will be welcome either by twitter or as comment.

Because of the use of powershell and azure I would recommend to install the latest powershell and the latest azure powershell by running

  # Install the Azure Resource Manager modules from the PowerShell Gallery
  Install-Module AzureRM

  # Install the Azure Service Management module from the PowerShell Gallery
  Install-Module Azure

Create VSTS
Create a visualstudio account or login to your existing and create a new project called “Workshop” using the scrum template
Create new at

Create a backlog with tasks
We are running a scrum template and we need to setup our first sprint with some backlogitems (go to work -> backlogs -> sprint 1)
Add backlog items: “Create a repository”, “Create a CI build”, “Add unittests”, “”. Then whenever you check in your code you can refer to it (VS add workitems, GIT use #{number}).

Create  a Git Repo and/or TFVC and choose if you use Java and/or .NET (GitCheatSheet)
Install Git
Create local repo
Connect to your team project

Connect your visualstudio to your TFVC repository

Did you know you can add both Git and TFVC to the same project 😉

Create Continuous Integration Build

-Martin Fowler:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

Because your CI build will be triggerd verry often this can’t take to long to give feedback, you have to re-think about what you want to have in your CI build and what in your CD pipeline and make sure the CI runs under 5 min. I see 5 minutes as the maximum because after that the developer who checked in probably picked a new task to work on or is not willing to wait for the build to finish. When a build breaks it’s a major disrubtion for the team and should be fixed within 10 min or so.

You can create one or more CI for a project try one or more of the following
CI using msbuild
CI using maven
CI using docker

Create a release pipeline
From here we will be working with the artifacts delivered from your CI build. It doesn’t matter what or how many artifacts you have you just put it in a box or have a (docker) container which you will ship through your different phases of deployment.

Add Azure endpoint
VM deploy pipeline
WebApp pipeline

Now you have your deployment to your development environment try expanding it to test, QA and production with the following criteria.
– each environment has its own usernames and passwords who cannot be saved in clear text
– as you probably noticed I used a fixed name for my VM but we want to have different names for each environment, fix the json add environment variables and pass them to the template to fix this
– each environment needs to be approved on before releasing to it
– when releasing from Git you only want your master branch to be able to go past your Test phase

Docker Pipeline
Create an SSH key from windows
Create an Azure Container Service
Docker pipeline

Create some unittests
Add Tests and publish your testresults
Creat code quality to your CI Build
Add Sonar for .net task
Enable Sonar for Java
Notice that in your history tab you now have a new entry with the changes you made to your CIBuild? Its fully audit-able, what is quite handy.

Now go to the URL provided in your endpoints and see the code analysis results.

Fully CI\CD as code

This is the end of the workshop if there is more time you can try one of the following:

  • Add application insights to your webdeployment
  • Create an Azure Container Service and deploy your docker container
  • Run another Yo VSTS
  • Install and run the dotnet CLI (dotnet new -t web) and use the .NETCore task to build it
  • Help others 🙂
  • Clean up your Azure Resources

On your way out don’t forget to provide us your feedback on the feedback board.

Thank you!

For this post the following websites where used:


You may also like...

1 Response

  1. April 12, 2019

    […] in 2017 I created a workshop for continuous delivery with VSTS into azure. That workshop is really outdated and could use a much […]

Leave a Reply