[Please note that I’ve edited this post since first publishing it to reflect new information and / or better ways of doing things. See revision list at the end of the post.]
It’s taken a few posts to get here but finally we have arrived at the point in my blog series on Continuous Delivery with TFS / VSTS where we actually get to start using TFS or VSTS – depending on the route you choose to go down. The main focus of this post is on getting up-and-running with these tools, but it’s worth talking a bit first about the merits of each platform.
TFS is Microsoft’s on premises ALM platform. It needs planning, provisioning of servers, and care and feeding when it’s in production. With TFS, you are in complete control and – disasters not withstanding – all data stays in your network. VSTS on the other hand is Microsoft’s hosted ALM platform. Pretty much everything is taken care of and you can be using VSTS within minutes of signing up. However, apart from being able to choose from a couple of datacentres, you don’t have the same control over your data as you do with TFS. Of course, VSTS is secure but if the nature of the business you are in puts restrictions on where your data can live, then VSTS may not be an option.
In terms of features, it’s a mixed story. VSTS gets new features about every three weeks and TFS eventually catches up a few months later – as long as you upgrade of course. However VSTS is missing some components that are present in TFS, notably reports (as in SQL Server Reporting Services, although Power BI looks like it will fill this gap) and SharePoint integration.
If there is no clear factor that helps you decide something else to bear in mind is that there is increasing adoption of VSTS inside Microsoft itself. So if it’s good enough for them…
Getting Started with VSTS
It’s trivially easy to get started with VSTS and the first five users are free, so there is almost no reason to not give it a try. The process is described here and within minutes you’ll have your first project created. I’ll be covering connecting to and working with projects in the next post in this series, but if you can’t wait I’ll tell you now that I’ll be using the Scrum process template and choosing Git for version control.
Getting Started with TFS
In contrast to VSTS, getting started with TFS is quite a lengthy process. For an on premises installation, you’ll need to do some planning however for a POC environment in the cloud, we can simplify things somewhat by using one VM to host everything. For some time now, Ben Day has produced an excellent guide to installing TFS and you can find the 2015 version here. The guide pretty much covers everything you need to know in great detail and there’s no point me repeating it. A high-level view of the process is as follows:
- Create a VM in Azure. I opted for a Standard DS4 VM running Windows Server 2012 R2 Datacentre which I created in my PRM-CORE resource group as PRM-CORE-TFS using the previously created storage account and virtual network.
- Configure a few Windows settings. The first part of Ben’s guide covers installing Windows but you can skip that as it’s taken care of for us by Azure. The starting point for us is the bit where Ben describes configuring a new server. One part you can skip is the Remote Desktop configuration as that’s already set up for Azure VMs.
- Install pre-requisites. Nothing much to comment on here – Ben describes what’s required with excellent screenshots.
- Install SQL Server. Choose the latest supported version. For me this was SQL Server 2014 with SP1.
- Install TFS 2015. Choose the latest version which for me was TFS 2015 with SP1. Be sure to create (and use!) the three domain accounts for the different parts of TFS. For me this was PRM\TFSSERVICE, PRM\TFSREPORTS and PRM\TFSBUILD. Make sure to check the User cannot change password and Password never expires settings when these accounts are created in Active Directory Users and Computers. Go with Ben’s advice and skip setting up SharePoint. It’s not critical and is an extra complication that’s not needed.
- One point to be aware of when installing TFS on an Azure VM is the installation wizard might suggest the D volume as the place for the file cache (D:\TfsData\ApplicationTier\_fileCache). This is a very bad thing on Azure Windows VMs as the D volume is strictly for temporary storage and you shouldn’t put anything on this volume you aren’t willing to lose. Make sure you change to use the C volume or some other attached disk if that’s the route you’ve gone down.
- Install Visual Studio 2015. Ben’s guide doesn’t cover this, but the easiest way to ensure all the components are available to build .NET projects is to install VS 2015 – obviously the latest version.
- I’m not sure if it’s strictly necessary on build servers but I always licence VS installations (Help > Register Product > Unlock with a Product Key) just in case bad things happen after the 30-day trial period expires.
- Another post-installation task I carry out is to update all the extensions from Tools > Extensions and Updates.
- Install TFS Build. TFS Build isn’t enabled as part of the core setup, which makes sense for scaled-out installations where other servers will take the build strain. (Don’t forget that build has completely changed for TFS 2015, and whilst XAML builds are still supported the new way of doing things is the way forward.) For a POC installation you can get away with running build on the application tier, and installation is initiated from the Team Foundation Server Administration Console > $ServerName$ > Build:
In reality, this just opens the Team Portal Control Panel at the Agent pools tab. From here, you need to deploy a Windows build agent. The details are described here and it’s pretty straightforward. In essence, you download a zip (that contains the agent plus a settings file) and unzip to a permanent location, e.g., C:\Agent. Run ConfigureAgent.cmd from an admin command prompt and respond to the prompts (TFS URL will be similar to http://prm-core-tfs:8080/tfs and you want to install as a Windows Service using the build credentials previously created) and you are done. If you chose default settings, you should end up with a new agent in the Default pool.
- Since you’ll almost certainly be needing the services of Nuget.exe, it’s a good idea to make sure it’s at the latest version. Open an admin command prompt at C:\Program Files\Microsoft Team Foundation Server 14.0\Tools and run Nuget.exe update -self.
Compared with VSTS, setting up TFS was quite a bit of work – several hours including all the installations and updates. Much of this activity will of course need to be repeated at every update. Not everyone will be able to go down the VSTS hosted route but if you can it could end up being quite a time saver.
Cheers – Graham
Revisions
- 9/1/2016 – Updated with type of VM to reflect adoption of premium storage and expanded installing TFS build instructions.
The post Continuous Delivery with TFS / VSTS – Commissioning TFS or VSTS appeared first on Please Release Me.
