Visual Studio Team Services = Git/TFS + JIRA + Team City + Octopus

Warning: The content of this post is highly opinionated. Please exercise caution. :)

A bit of Background

Back in 2012-13, the term Dev-Ops was unheard of in my team. We were still living in dark ages where a developer would developed the code, then write unit test cases more to get the code coverage look good than to actually “test” the code. The code would then go through a review and queued for check-in. Some magic which the developer never really cared about would then tell us if the code was successfully checked-in or it failed. That magic was TFS XAML  build. The build was managed by a dedicated team and we never felt it was part of development process. After the end of sprint iteration a huge code base would then go to the test team and they would start testing the code based on their test cases and log bugs to the dev team. More often than not a developer would talk to tester only during that phase. This resulted in 100s of bugs in a big team. Few of these bugs would be invalid due lack of understanding of requirements, few others would be basic bugs which should have been handled by the developer in the first place. All the requirements, tasks, bugs, issues etc were logged in TFS. But, there was no dashboard. So, every developer and dev lead had to be expert in excel to track the items more effectively. It is said Ignorance is bliss, and same was true for us. We were happy in our shell, delivering code in this fashion and never felt need of change.

During the similar time-frame, I got an opportunity to work in a customer location. This is when I got a rude shock. The customer used tools which I had not heard before. They used confluence to collaborate, JIRA to track work items, Team City for build and a source control that was not TFS :). Suddenly, I realized that development was more than just writing code. I fell in love with these tools immediately. I realized there is more in the world than TFS.

However, there was still one big pain point with all these tools and application. We were using just too many tools and plugins – TortotiseSVN, JIRA, Team City, some other tool for deployment etc. Each one of these tools looked different and they worked differently.

Visual Studio Team Services

Microsoft was late to join the party and TFS was surely lagging the features that Agile projects and modern development practices demand. In 2013, Microsoft introduced Visual Studio Online (VSO). At the time of launch VSO appeared to be nothing more than TFS on cloud. However, Microsoft started adding more and more features to VSO. Many of these features were “inspired” from competitive tools. Over a period of time, VSO was aptly renamed to Visual Studio Team Services (VSTS). Today, VSTS has become one stop for all our development.

VSTS has solved one big problem of fragmentation. Its features today are on-par if not more with JIRA, Team City and Octupus.  With VSTS as a user you do not need multiple accounts,  your single account will give you access to everything you need for software development. Additionally, VSTS now offers full support for more and more non-Microsoft services. That means, you are first class citizen irrespective of your editor, source control (TFVC,  Git) and technology. If you do not want to use VSTS for everything, you still have a choice to choose what you want. For example, you can choose Octopus over VSTS Release Management and push package from VSTS build to Octopus directly. It works seamlessly.

To know more about features of VSTS go here. What tools do you use for your development?

Advertisements

Publish Web App to Azure Virtual Machine – Part 2

This post is Part 2 of the series – Publish web app to Azure VM. In this post I will take the application, we created in Part 1 and publish it on Azure Virtual Machine through Visual Studio Team Services.

Before you go any further I you recommend to go through Part 1 of the series, if you have not already.

As a pre-requisite I have assumed that your solution along with the publish profile you created in part 1 is checked in Visual Studio Team Services. For this demo I have used the Team Foundation as my version control. But steps are same if you have used Git as your version control.

Publish Web App from Visual Studio Team Services

First, go to your Visual Studio Team Services dashboard of your project. Your visual studio team services dashboard should look similar to the figure below:

visual-studio-dashboard.PNG
Visual Studio Team Services Dashboard

 

Now, click on Continuous Integrate to create your build definition. This will take you to a new page where you will see a “+” icon on left navigation pane. Click on icon to create a new build definition and then select Visual Studio template.

CI - step1.png
Create new build Definition

Click next, select your repository in the second step and then click create.

Your build definition will have some default build steps added. Keep only Nuget restore and remove rest of the build steps as this demo is focussed only on publishing the build to Azure VM.

ci-step3.PNG
Visual Studio Definition – Nuget restore build step

Next, click on Add Build step and add MsBuild task from Add build step window. We will use MsBuild to publish the publish profile we created in first part of this series.

Now, select MS Build step and specify your MsBuild arguments as

/p:DeployOnBuild=true /p:PublishProfile="$(publishProfileName)" /p:Password="$(userServerPassword)" /p:Configuration="$(BuildConfiguration)"

Let us go through each argument one by one:

  • DeployOnBuild: Setting DeployOnBuild to true means, we will deploy the solution after building
  • PublishProfile: Defines the name of the publish profile we use for the deploying. We have provided the value of publish profile as user defined variable, $(publishProfileName). We will define this variable later.
  • Password: Defines the user password of the Azure virtual machine. Again, we have provided the value of password as variable $(userServerPassword) which we will define later.
  • Configuration: Defines the build configuration of the solution. This build configuration value can be either be release or debug based on kind of deployment you are doing.

With this our build steps are completed.

ci-step4
Visual Studio Definition – MS Build Step

Next, we need to define the variables we used in MSBuild step. Select Variables tab in the build definition. Click, Add variable and give the variable name as publishProfileName. Provide the value of the variable same as the name of your publish profile. Click, on Add variable again and give the name of variable as userServerPassword. Provide password of Azure VM user in the value field of variable. Since, password is sensitive information, make sure to click on the lock icon present on the right side of the variable field.

For both the variables also check Allow at Queue Time. This will prompt the user to change the values of variables before queueing the build.

Also, notice that variable $(BuildConfiguration) is created by default so we do not need to add it again.

ci-step5.PNG
Visual Studio Definition – Variables

Next, you can optionally define the when this build definition would be executed from Triggers tab. You can chose to either build each check-in (Continuous Integration) or schedule it at a specific time.

Now, click save and provide the name of the build to complete our visual studio definition.

ci-step6.PNG
Visual Studio Definition – Save

With this all our build definition is complete. Now, just queue you build and verify that publish to Azure is successful.

ci-step7
Queue Build

Important Note

Your build definition may fail with error #ERROR_CERTIFICATE_VALIDATION_FAILED. This error comes up because the remote server has a self-signed certificate for the Remote Agent Service or the Web Management Service. In this case, you need to bypass the certificate validation. Go to your publish profile in your solution under Properties -> PublishProfiles. Add below line to the property group

<AllowUntrustedCertificate>True</AllowUntrustedCertificate>

This option should NOT be used for Production. In production make sure to have a valid certificate on remote server.

 

Publish Web App to Azure Virtual Machine – Part 1

This post is two-part series where I will explain how we can publish a web app to Azure Virtual Machine.

In the Part 1 of this post I have explained how to publish a web app directly from Visual Studio. In the Part 2, I will publish the same web app from Visual Studio Team Services.

Important Note: Publishing a web app from Visual Studio directly should be use only during development. Usually, developers do not have access to Production VMs.  In Production you can use PowerShell script to publish the web app outside the Visual Studio.

Prerequisites

  1. Active Azure Subscription. Create your free Azure account if you don’t already have one.
  2. Windows Virtual Machine on Azure: Follow these steps on to create an Azure Virtual Machine. For this demo I have created “Windows Server 2012 R2 Datacenter” with deployment mode as “Resource Manager“.
  3. Visual Studio 2015 – Update 2 with Azure SDK 2.9 or greater.
  4. Code repository on Visual Studio Team Services: Create an account on Visual Studio Team Services and set up your code repository using Git or Team Foundation Version Control. I have used TFS as my version control for this demo. This step is required only for part 2 of this series.

Configure Virtual Machine

1. Open http port 80 and web deploy port 8172

Our first step is to open http port 80 and web deploy port 8172 on Azure VM. In the classic Azure VM this step is straightforward. All you need to do is to create an endpoint. While port 80 is opened by default, you can follow these steps to open endpoint 8172.

In the Azure Resource Manager (ARM) VM we need to open both ports 80 and 8172. You can follow my previous blog post where I have explained how add an Inbound security rule to open port 80 on the Azure VM. Similarly, you need add an Inbound security rule to open port 8172 on the VM.

Your Inbound security rules window on Azure portal after adding rules to open the port should like figure below:

inbound-security-rules
Inbound security rules

 2. Configure DNS Name

With classic Azure VM, the cloud service is created automatically and you do not need to do anything special to configure DNS name.

To configure DNS name with ARM VM, follow the steps to configure azure vm in my previous blog post.

3. Set up web deploy on remote machine

Now, remote desktop on your virtual machine and install IIS on your machine. To install IIS, go to Add Roles and features Wizard and select Web Service (IIS), under Application Development select all options.

Now, install Web Platform Installer 5.0 on your server from this link. Once installed search for web deploy on the Web platform installer. Look for “Web Deploy 3.6 for Hosting Server” and install.

web-deploy-install.PNG
Install Web Deploy on Azure VM

The next step is to create a website in IIS where we will host our application. To keep the things simple for this demo, I will deploy my application on Default Web Site. Now, select your website from IIS. Then, under IIS Manager Permissions add user with appropriate permission.

iis-manager-permission.png
IIS on Azure VM

Before we proceed further make sure that you have opened port 8172 on Windows Firewall. For this you need to create following firewall rules on your machine:

Direction From Port To Port Port Type
Inbound Any 8172 TCP
Outbound 8172 Any TCP

Publish Web App from Visual Studio

For this demo I have created a simple MVC web application from the standard visual studio template. I modified the home page to show my machine name and hosting server. On local, my homepage looks like below:

localhost-homepge
Web App on localhost

Now, the next step is to create  a publishing profile to publish the web app directly from Visual Studio to Azure. Select the project, right click and select publish. On the publish window, expand More Options and select Microsoft Azure Virtual Machines.

select-azure-vm-option1.png
Select Publish target – Azure Virtual Machine

You will be then asked to login to the Microsoft Azure account. Login to your Azure account and then select the Windows VM you have created already.

select-azure-vm
Log in to Azure subscription and select Virtual Machine

Click Next and provide your publish details. Keep the publish method as “Web Deploy“. Do not change the server details. Provide the name of the site you created in previous steps. Provide your VM username and password.

publish-web
Validate Connection with Azure VM

 

Now, click Validate Connection to validate your connection. You may get a Certificate Error. This error comes up because the remote server has a self-signed certificate for the Remote Agent Service or the Web Management Service. Click Accept to bypass certificate validation.

validate-certificate
Bypass certificate validation

 

Click “Next” and then “Publish”. Once, the publish completes go to the publish URL to verify that the web app is up and running.

remote-homepage
Web App hosted on Azure Virtual Machine