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

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 http://yoursite.scm.azurewebsites.net, 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!

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 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>.database.windows.net in the sonar.properties file:

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

I updated SonarQube to 5.6 and nothing works any longer, should I panic?

SonarQube 5.6 is the new LTS release, hence there are lots of changes.

The first step where you might panic is when you launch it for the first time, you will find this:

ce is the Compute Engine, a process for data aggregation on the server.

Don’t worry, Process[ce] will eventually go up after you run http://<your SonarQube>/setup and migrate to 5.6.

Then, this at build time:

SonarQube comes with no plugins out-of-the-box! Remember to bring yours from the old installation and update them after the system check..