Upload Custom Build Tasks On-prem TFS 2015 Update 2

One of the great features that TFS 2015 Update 2 brings to the party is the ability to add extensions and custom build tasks.

I was sorely missing the SQL dacpac deployment task that has been available on VSTS for a while, so I decided to upload it myself.

First of all, all the source for the VSTS / TFS build tasks is actually available. If you have not already, head over to Microsoft's GIT repository and take a look for yourself. You may notice that the SqlServerDacpacDeployment is just sitting there, ripe for the picking…

To get the build tasks uploaded to your on-prem is not as straight forward as it would seem though. First of all, you need the TFS Cross Platform Command Line (tfx) command line utility to upload the build tasks. It in turn requires NodeJS. Once all that is installed you can start uploading your extensions and build tasks… well almost.

Tfx does not yet support integrated authentication, and on-prem versions of TFS do not yet have "Personal Access tokens" or PATs. Tfx does however support basic authentication, which means we need to tweak our TFS instance a bit to be able to upload our own tasks.

We need to get onto the TFS server and open up IIS. Select the "tfs" application under the Team Foundation Server site and enable basic authentication.

Once you have done that you are ready to upload your tasks. After downloading the task repo from Microsoft I simply opened up a command prompt and executed the following command :
tfx build tasks upload --service-url http://<<server>>:8080/tfs --auth-type basic --username <<username>> --password <<password>> --task-path .\SqlServerDacpacDeployment

Interestingly enough that did not work, for the life of me I could not see the task in the list. I eventually figured out that in the task.json manifest there was a "visibility" section. The first item was "preview" and this seemed to stop the task from being "shown" somehow. After removing that it worked like a charm.

"visibility": [
   "Build",
   "Release"
],

Now I can play around with deploying dacpac's

Intro to VS Team Services Extensions

Over the last couple of months I have been quite busy with various VSTS extension as part of the ALM Rangers.
You can see some of the extensions that I have developed here and here, and I am currently involved with at least 3 others.

As a quick guidance we decided to do what we call a brownbag session (informal, bring your bagged lunch and listen in type of session) to try and get more of the rangers involved and up to speed.
The session was published on channel 9, so if you are interested in getting up to speed on creating your own extensions, feel free to give it a listen..

Feedback is always welcome.

Multiple TFS_Configuration databases on a single SQL instance

I have been doing a number of upgrades over the last couple of months and have found that doing a migration to a test/dev environment is a good way to gauge the downtime needed to perform an upgrade on the TFS Collection databases.

This works well if you have a spare set of servers / VM's lying around and you are able to do a full migration. I have been in a situation where a new application tier was not much of a problem, but they had an enterprise SQL server setup that we "had to" use.
Even though the "duplicating" of the collection databases is no problem at all, the tfs_configuration database is a different story.

The options are:

1. Install a temporary SQL server on the application tier and simply use that for the tfs_config database or
2. Duplicate the tfs_config and then either "point" tfs to the instance in question or select the correct database during (re)configuration

To perform option 2,  simply create a backup of the tfs_configuration database and restore under a different name (on the same server). When you perform an upgrade or (re)configure the TFS application tier you have the option to select the "correct" config database:

If TFS is already configured and you want to change the database after the fact you can follow these steps:

1. Open up command prompt (run-as admin)
2. Go to the TFS tools directory (for 2015 the default is C:\Program Files\Microsoft Team Foundation Server 14.0\Tools )
3. Put TFS to "sleep" : TfsServiceControl.exe quiesce
4. Backup and restore the config database to the new name
5. Re-register the database : tfsconfig.exe registerdb /sqlInstance:<<sql-server>> /databaseName:<<new config db name>>
6. Finally, wake TFS up : TfsServiceControl.exe unquiesce

That should have TFS pointing to the new config database, meaning you can have multiple TFS instances using different configuration database hosted on the same SQL server.

Need help upgrading ? : give us a shout

TFS 2015 Update 1 RC

In case you have not noticed RC 1 for the first update to on-premise TFS 2015 is in release candidate.

Amongst others, my favourite new bits are:

1. Dashboards
2. Card colouring

Yours?

Need help upgrading ? : give us a shout

TFS 2015 Finally released!

After waiting what seems like forever, TFS 2015 has finally been released after Brian Harry decided to hold back and get some more testing done.

This time it seems to be the real thing : http://blogs.msdn.com/b/bharry/archive/2015/08/06/team-foundation-server-2015-final-release.aspx

I've had some people ask me if they should upgrade or wait a while to have all the "kinks" worked out. My answer is twofold:

1. Evaluate the release first and make sure that there is value to be had out of the upgrade
2. Secondly, I would not worry toooo much about encountering any "kinks". TFS is pretty much production tested in VSO so there is not much of a chance that you will encounter any significant issues

If it makes sense for you to upgrade, by all means do (of course taking necessary precautions as you would in any upgrade situation!).

That said, it is always a good idea to keep up to date with updates and upgrades. This will make future updates less cumbersome and quicker, as well as keep you in the support band (TFS 2010 is not supported anymore and Visual Source Safe should not exist anymore!! (even though the tragic truth is I'm still doing the odd VSS migration ))

It should be noted that this will probably be a longer update/upgrade than most. There are some significant database changes due to the project rename (finally!) capability that was added. In most small TSF instances this will not be much of an issue, but I have dealt with some large instances that needed careful planning! Luckily there are ways and means to make it a bit easier.

Need help upgrading ? : give us a shout

Visual Studio 2015 RTM on July 20th

woohoo.. finally the RTM date for Team Foundation Server 2015 and Visual Studio 2015 has been made public…

http://blogs.msdn.com/b/somasegar/archive/2015/06/29/save-the-date-visual-studio-2015-rtm-on-july-20th.aspx

Edit: Visual Studio will be released, but Brian has decided that quality is more important than timelines.. So we will have to wait a bit longer for TFS 2015 to land, but be assured the quality will be right up there

Need help upgrading ? : give us a shout

Installing and configuring TFS 2015 on-premise xplat build agent

One of the things that really got me exited about TFS 2015 was the cross platform build capability, and that was the first thing that I started to play with as soon as I got hold of the RC.

Interestingly enough, in VSO it is fairly easy to setup when you have the "alternate credentials" on VSO, but, as I was to discover, there are a few more things that you need to do before you can get it working on-prem.

So with my TFS server and newly installed Ubuntu box ready, I started the xplat (pronounced "cross plat(form)" if you were wondering) configuration. The install was fairly straight forward as per the steps indicated. Then came the configuration.

1) Authentication
The first thing the vsoagent configuration asks for is an account to run the xplat agent under. Linux does not play well in an Active Directory environment, and I have spent waaayy to much of my life trying to get linux working on AD. This hinted towards authentication problems…
But there is a Solution
VSO has the concept of alternate credentials, which is basically a "Basic Authentication" mechanism. What we need to do on-prem is to enable this type of behaviour.

1. Log onto your TFS Server and install Basic auth on IIS 
2. Go to the TFS application in IIS (Sites\Team Foundation Server\tfs) and enable basic auth
3. Edit and set the domain and realm to the domain used for authentication

2) Security
Once you have the authentication mechanisms setup you need to pick the account that the agent is going to run under and assign the correct rights in TFS and in the build pool. To set the rights for the build pool you need to

1. Navigate to TFS server web access admin screen (http://<<server>>:8080/tfs/_admin)
2. Go to the "Agent Pools" tab and either create a new pool or select the default pool
3. Then assign the account that the agent is going to run under into the "Agent Pool Service Account"

Not doing this may give you a "Failed Request: Forbidden (403)" error when you try and run the agent

3) Boot her up…
Finally you need to "boot her up". If you have followed the steps outlined here, you should be able to run "node vsoagent" in the agent folder of the newly "installed" agent and you should see something like this beauty..

and in TFS :

and "thar she blows"..

Please note that it… .. use at own risk