As you’ve seen me post before, I use the Multilingual App Toolkit in my Upload to YouTube app to localize it in to many languages. Since MAT is an installed extension to Visual Studio (and msbuild), however, setting up Upload to YouTube for CI and Release builds done in my Visual Studio Online account ended up being an impossibility.
Why? Because VSO builds are done on shared servers. The VSO team doesn’t install anything other than the bare necessities to make these builds happen. Imagine if they fielded and acquiesced to every request to add an installed extension to their build boxes – they’d be reduced to shambles in no time, as pointed out by VSO’s own Buck Hodges.
@bc3tech @bharry We struggle here. There's no way we can have all the SDKs folks want. We need the SDKs to come in via NuGet to…
— Buck Hodges (@tfsbuck) December 10, 2014
The solution? Use NuGet for your dependencies, not installed SDKs or toolkits. Or if that’s not an option (as it isn’t with MAT, Ad SDK, and other things), another great suggestion was given to me, once again by Buck:
@bc3tech @bharry Just run the normal installer on the VM, and tell it to connect to your account. It will guide you. http://t.co/4MizEBpdzX
— Buck Hodges (@tfsbuck) December 10, 2014
@bc3tech @Azure @bharry The TFS installer and just choose to configure a build agent. You can get TFS installer at http://t.co/BAwNn3DeXa
— Buck Hodges (@tfsbuck) December 10, 2014
Create your own build server. And as he points out, you can even wire it in to your Visual Studio Online account and use it in your TFS Build Definitions. So without further adieu, let’s jump right in, shall we?
Step 1 – Create an Azure VM
Just create a blank Server 2012 one. Don’t try using the TFS image or anything. Reason is because you don’t want a full TFS server, you just want a build controller and agents. This is a much smaller portion of the install than the full blown source control, defect tracking, etc.
Step 2 – Download and TFS Express/Full
Looking through the link Buck posted, you can find TFS Express Edition. If you don’t have more than 5 developers on whatever project you’ll be using this with, this is what you want. Otherwise go grab TFS from MSDN or another official channel.
After you’ve obtained the correct installation, run the installer. I know, it seems a little weird that you only want the Build Server components but are presented only with an “Install Now” button, but go with it ;)
Step 3 – Configure installation as Build Controller & Agents, wire in to VSO account
At the end of installation, you’ll be presented with the Configuration Center screen
Since all we’re interested in are the Build components of TFS, select the ‘Configure Team Foundation Build Service’ node on the left, and then Start Wizard.
When at the Team Project Collection page, you might wonder what’s going to happen when you click Browse… – well, as I often do, click it and see what happens.
If this seems familiar, it should – it’s the exact same dialog you see in Visual Studio when you go to set up a new Team Project Collection and/or Team Foundation Server to access other projects. So I bet you can guess what happens when you click ‘Servers…’
Sure enough, you’re presented with the same dialog to add/change servers, and can add your VSO server in here, just the same as you already have in Visual Studio.
Click ‘OK’ and authenticate via your Microsoft Account and you’re in! Now, we were trying to add a Collection to our Build Server setup, so choose the Team Project Collection you want to work with (most likely DefaultCollection) and click ‘Connect’
Click ‘Next’ to set this TFS instance up as the Build Server for the chosen collection. I suggest using the default settings and number of build agents to start, you can tweak them later if you so choose.
On the Settings page, I chose to have my Build Server run as a local System account. I know this might be a bit more risky from a security standpoint as you can’t lock things down as much as you might want/be able to if you configured a user specifically for the service, but that’s not the point of this post ;)
At the next step you get a nice summary of what’s about to happen, which I always appreciate.
Once you get the All Clear from the Readiness Checks step, move on to Configure. At this point it does the actual work to set up the TFS instance on this machine the way you specified. Hopefully you’ll be met with something like this:
GREAT! Now your Azure VM is all set up as a TFS Build Controller (with agents) for your Visual Studio Online account! Now… how do we use it…
Fire up Visual Studio and open a project from VSO. Head to the Team Explorer and edit one of the Build Definitions you’ve created.
Head to the ‘Build Defaults’ page and you should see something like this:
Except now…
There’s your new build controller ready to do your bidding! Changing it here means every time you queue a build manually it will be the one selected by default, or every time the build is triggered it will use this one by default. If you want to leave it as hosted, you can use your custom one during the manual queuing process:
Mind you you’re not quite done just yet. Nothing will build on your new controller until you install a flavor of Visual Studio (to get the msbuild tool chain). And don’t forget the whole reason we did this – because you’re using some 3rd party SDK that wasn’t available on the hosted build servers. So don’t forget to install those as well!
Hope you enjoyed this post. Have fun with your newfound freedom in your VSO build environment.