Thursday, 21 July 2016

Review – Professional Visual Studio 2015

WP_20160720_001 This is a book I keep reviewing at every release, and for good reason: it is not mainly aimed at seasoned users of Visual Studio but at beginners approaching this IDE for the first time.

This is why you won’t find many changes from 2013 to 2015 – because an IDE doesn’t change as much. But I still recommend it, because of its role as a one size fits all overview of the development stack we use these days.

It is still worth it if you need a reference on your shelve (like I do Smile), or because it also has good and quick code examples. Eventually I realised one of the biggest improvement is the size of the font from last version’s – it is more readable.

Tuesday, 12 July 2016

A first look at TFS 15: the new Build Agent

Another big change in TFS 15 Preview is the new Build Agent.

This doesn’t mean there is yet another build server (the new Team Build is here to stay Smile), the big news here is that the new Agent is cross-platform by default, because it is written in .NET Core!

You can set it up as usual from the main _admin page. Once you add the new Agent, you can select Windows (preview):


You need to add a user as Agent Pool Administrator to run this new agent, as per documentation:


Once you start it, you would be prompted for some configuration settings. It is very easy and similar to the old agent:


All done!

Remember it is a preview, and if you want to start using it that this agent is a replacement for the Node.JS agent. So if you want to keep using TFS 2015 in the meantime do not replace the Windows Agent that comes with it.

As usual, the code for the agent is on GitHub.

Friday, 8 July 2016

A first look at TFS 15: pre-production upgrades

In the last post we saw how to install and configure TFS 15. What about upgrades?

Well, there are some changes… Smile

Starting from the usual wizard, you will select the option for existing databases:


Then you need to point it to the appropriate database server – nothing new here:


Now, this is great. Do you want to run a Production Upgrade or a Pre-Production (testing!) Upgrade?


Let’s go for the latter, as the Production Upgrade is exactly what we have in the current version and there are no changes to that (except for Search).

The next step is pure guidance:


All the TFSConfig commands are going to be executed by the wizard, which means that the headaches from test upgrades and the risk of conflicting with a production instance are now gone!

This is the list of what actually happens at this stage:


There are suggestions, as you can now see:








This is really brillant. All the steps are actually the same as a production upgrade, but with all these added tips and especially with the automated cloning steps at the beginning this new wizard really brings value to the TFS Administrator.

Here is the result:


Note that Search is not automatically installed during an upgrade, because it is an opt-in service and given the deployment size it might lead to performance issues installing it by default.


Upgrading also means the new Work Item Form is disabled – it is another opt-in feature. Once you enable it, you can configure who can request it:


This is really a fantastic job by the TFS team!

A first look at TFS 15: installation

Yesterday Microsoft released Team Foundation Server 15 Preview, and I could not resist installing it as soon as possible Smile

The installation process is the same:


What changed is the configuration process:


The configuration of TFS changed to make it more streamlined in its own wizard, but the first thing I saw was the possibility of configuring a Search Server.


This is because the Code Search feature relies on Elastic Search, and if you have a large deployment it is really suggested to have the Search Server on its own with high performance disks supporting it. More on that later Smile

The TFS configuration now asks for the deployment topology you are using or you are planning to use.


Let’s go ahead with a new deployment, and we will be immediately faced with a choice:


Selecting the Basic scenario the only two things we need to set are the SQL Instance (SQL Express as a default, otherwise an existing SQL Server. Nothing changed from the previous versions):


and Search:


Note that the wizard explicitly suggests using SSDs for Elastic Search. I can tell you, they really help here.

If instead we are going to choose an Advanced scenario…

tfs15_6…we are going to configure the database settings first:


Then the service account and the IIS configuration – nothing changed from previous versions. Search is up next and we already saw the configuration required, then Reporting Services and SharePoint.

Nothing changed for SSRS and SharePoint, but I really like the recommended suggestion (enabled by default! Smile) of using separate accounts for SSRS and Service Account.


Eventually, change the name of the DefaultCollection if you wish:


Is that it? Not really. During the pre-requisite checks you will surely see this error:


Elastic Search is a Java product, hence a JRE is automatically installed if not found on the machine. Beware, this is always the latest version of the server JRE, so it is slightly different than the usual JRE (it doesn’t feature in the Installed Programs list, it doesn’t have a browser plug-in, etc.).

There is also a new port to open for it, 9200.

Tuesday, 28 June 2016

Small but noticeable: SSH Service in TFS 2015 Update 3

One of the features introduced in TFS 2015 Update 3 is the backport from VSTS of SSH access for Git repositories.


There is a very nice document on how to use it, so I am not going to look at that, but what is interesting is what happens on the server at upgrade time.

You can decide whether to enable the service or not:


and this will automatically create its firewall rule:


Moreover, you can manage the service from the Administration Console:


A small touch, but much appreciated from an administrative point of view Smile

Monday, 13 June 2016

A simple VSTS-based pipeline for Java Web Applications

I took the plunge last weekend about building a pipeline for a very simple Java application, and it was very, very easy to do so.

The app in question is DeepSpace. It is written in Java and AngularJS, so it looked like it was perfect for my requirement. It is used in the VSTS Java demos, but I didn’t want to go down that route because of the deployment approach.

What I wanted to throw in the mix is Azure Resource Manager of course, I am not going to use FTP and manual credentials from a .publishsettings file anymore! So the first thing I did was to create an ARM template for my website.

What does it take to deploy such an application on VSTS? Well, I would say around ten minutes, tops. I realised Donovan Brown did the same thing, it would have saved me a bit of research!

Start with the build: VSTS has Maven running in the Hosted Build, so there is no setup cost you need to factor in for the build server:


The pom.xml file is kindly provided by DeepSpace, but it would not take long to have one. You can see I am packaging the application (so I would get a .war file, more to come later on the matter) and I am using JaCoCo for Code Coverage – again provided by the Hosted Build.

The next step is publishing the artifacts to VSTS. Nothing really fancy here – just push the .json and .war files.


So, we built our stuff. Now we want to push it to Azure I reckon. Release Management is definitely the right tool for this job.

I am using the Trackyon Advantage task like Donovan because I realised Tomcat is not exposed if you create a Java-based Azure Web Site with ARM, and you can’t change its configuration because it would be running under Program Files, where the user doesn’t have edit permissions.

By the way, if you want to have a look at what happens to your Azure Web Site, at what’s inside and if you want to run a cmd, browse to, where Kodu would provide a great amount of information and you can actually browse and edit (where possible) things.

So, back to RM – I am going to change the format of the .war file to a .zip compatible with MSDeploy so I can reuse the Azure Web App Deployment task and I am not going to fiddle with Tomcat (which means not getting near any credential or custom file modifications, which in turn is very good for automation!). If instead you need/can access Tomcat, use the VSTS extension for this.

I am literally just providing paths here:


Then I am going to deploy my ARM template as usual (it is made of a single Website and Azure App Service at the minute), and I am pushing my Web App as well:


That’s it! I wasn’t expecting it to be that easy – the only place where I stumbled was the war to zip conversion.

What I did was searching on the Marketplace for “war zip”, I had a look and Trackyon Advantage was there among the other five results. I looked at the description and it did what I was searching for. There is literally an extension for everything these days!

Of course the pipeline lacks stages, approvals and all the rest. But this is what I put together in around an hour, so it is a great starting point!

Friday, 10 June 2016

Moving a SonarQube installation to SQL Azure Database

There might be a tons of reasons behind it – you might want to take advantage of SonarQube’s support for SQL Azure Database, and it is totally fair enough.

There was a showstopper in the past if you were on 5.5 – this bug, fixed with the 5.6 release.

So let’s move! But upgrade to 5.6 first, on-premise Smile so you are going to have a clear starting point.

The first thing you need to do is to create a new SQL Azure Database in your subscription. Call it like the one you have on-premise, and use the same collation (tip: remember CS_AS…) for peace of mind.

Then (unless you are using SQL Server 2016) run the SQL Azure Migration Wizard. This tool will do everything on your behalf, and it is going to migrate the database in the cloud.

If you get any connection error here, remember that SQL Azure is locked down for external access – you need to add the IP address for client connectivity to the Azure Firewall:




As you would be using SQL Server Authentication, you also need to create a SQL User for SonarQube. Even if you already used that, the users are not migrated by the tool so it is something to do anyway.

Eventually, change the SonarQube database connection string to your new <azure DB> in the file:


Done! It is really easy, and if you are moving from a SQL Server Enterprise Edition it is also cheaper.