I haven’t posted in a while, but recent projects got me thinking. I have had the opportunity to work in many environments with a range of tooling and processes over my career and there is one tool more than any other that I find a genuine hinderance on a day to day basis. This tool is Microsofts large ALM offering – TFS.
To put things in perspective, I thought I would give a little background. I have been working in development for around 15 years and specifically with .net based CMS systems for pretty close to 10 years, during this time I have used a load of tools to achieve various aspects of development. TFS in particular I have used for around 4 years now (note – I have not seen TFS 2015 as yet, but I believe that many of the same fundamental issues will still exist.). As I am sure you are aware, TFS is broken down into a number of fundamental components. I will quickly run through each and what I believe to be the pitfalls in their day to day use. Before I go further – I don’t believe TFS is the devil incarnate, I think it works just fine for solutions that are entirely in the MS stack where files are not subject to quick change – stuff like – windows phone apps / windows desktop apps / console apps maybe. I think in the web world it is more trouble than its worth and here is why:
Source Control – Traditional TFS
So first is probably the most obvious function of the TFS ecosystem, the source control management system. This in the case of regular TF source control has a range of fundamental flaws in my opinion which are particularly shown when working with Sitecore solutions.
- Server based – this causes quite a lot of slow down when working with tools like TDS / Unicorn (particularly the former) as every time an item is created in the VS project (whilst connected to the TF Server), the tools insist on informing TFS that the add is happening (mainly to see if the csproj is checked out and whether the file in question is), when connected to a git / svn project, the files are simply known about because they are on disk.
- Branching – TFS and svn are similar in their branching model – they fundamentally create a (sort of reference) copy of the source, however even svn has distinct advantages over TFS. TFS has an insistence on knowing where the project is mapped to on your disk, if you want to download multiple copies of the same source (which there is often actually a need for), then you must create multiple workspaces – this all gets fiddly. Svn simply requires a checkout to a new location and job done. Simpler still – Git will allow you to change branches in the same location. Branching in TFS also requires higher levels of permission (unlike svn / git) and in many organisations I have worked with, has not been available to me from the off – a huge source of frustration.
- Integration with other systems – Yes – you can make it work, but generally any system that has a requirement to integrate with TFS Source control requires something like Team Explorer to be installed. This is particularly frustrating when dealing with servers like TeamCity / Jenkins (if the latter is even possible) and on occasion deployment servers like Octopus (though I wouldn’t recommend that as an idea), and especially so when you (as developers) don’t have permissions to set up machine like that – it’s just another thing you have to explain to IT. This is even worse when you look at TFS online, since then you have to deal with the crazy SSO system too.
- Insistence on VS integration – If I had £1 for every occasion where a file was missed during check in because either a) the file was added in a location that is not included in the visual studio project or b) that visual studio decided to ignore altogether due to internal rules (.dll in a bin folder for example).
- Lack of proper exclusions – when working on large web projects, including Sitecore, it is often necessary to control the exclusion of files on a pattern basis. The obvious ones might well be generated files such as search indexes or media caches, but think less than that, think – configs, data files. Sitecore is incredibly config rich and its likely that on many occasions you will want to have config changes specific to your machine and not be committed – moreover, these config changes be ignored if you say – send it to the guy across your desk. This with TFS is possible, but clumsy and requires elevated rights to prevent check in, you can temporarily exclude them in the IDE, but invariably when a dev is under pressure and clicks the ‘include all’ button, they can inadvertently find their way into source control or worse.
- Windows specific – (technically I know that there are some solutions to allow you to use it on a mac / linux box) generally speaking – TFS limits the users to windows. The majority of front end developers that I have worked with of late (and like me – many of the back end developers) work on Mac. There are a tonne of git and svn implementations for a Mac / Linux / Windows
Source Control – Git
So – A while back (TFS 2012 + I think), Microsoft gave consumers the choice of using Git as their source control tool of choice. This on the face of it seemed awesome (and believe me when I say, its still a better option than TF Source control). However, even this has a number of pitfalls.
- Integration – TFS servers by default come configured to rely on Git over HTTPS, this requires NTLM (which can be turned off) authentication by default, which annoyingly still means that if you are trying to talk from a java based tool such as Jenkins / TeamCity, you still have to mess around. Add to this a known bug with TeamCity when using HTTPS and what (as far as I know to date) is a lack of support for SSH and things get worse still.
- Git doesn’t support many of the TFS specific features – required issues on commit for example
- Visual Studio Git Support – well – tbf – this is just woeful in my opinion, and suffers from many of the integration problems above – if you want to use Git, first learn the command line, then (if you want) pick a tool that is Git specific that you like (and still revert to the command line for many operations).
I also think there are several occasions where TFS Git doesn’t behave as normal Git would, but am struggling to remember examples at this time.
TFS Build & Release Management
TFS build seems to be one of the weaker points of TFS when it comes to builds with Sitecore. To create a decent deployment strategy with Sitecore requires quite a bit of flexibility from your build & deployment servers, since in general you will not be starting with a complete copy of Sitecore in your visual studio solution. Its also not uncommon for example to have the static assets coming from one repo.
The way that the default build behaviour spits out the assets from your build is actually somewhat distributed and doesn’t seem to result in a nice easy way to say ‘grab these files from here’ means that inevitably you seem to HAVE to control your build process using powershell.
Add to this you have the restrictions that the UI brings. The majority of ‘good to go’ calls in the real world are not made by the developers who write the software, it will often be QA or the product owner. This should mean that they are the ones responsible for hitting the button to make it so. TFS has a large reliance on Visual Studio (though the web front end is getting better) that this becomes a real pain for
Tools like TeamCity / Octopus allow a much simpler – click to deploy experience for an average user in my opinion.
I have ran many a project in this – simply put – I dislike the Visual Studio interface and find the Web interface miles behind pretty much all of its competitor tools.
Unless you are a Microsoft partner and get the applications for free, the cost is pretty great when compared with alternatives. If you run it in house, the level of hardware required also seems excessive. The cloud solution makes it much more cost efficient, but still not amazing.
In terms of setup & maintainance – Setting up a consistently working solution in TFS that performed the same task as the builds using my regular choice of tooling took around 5x longer and was much trickier to debug when things started to go wrong.
My personal preference is to use a mix of Bitbucket, Jira, TeamCity & Octopus Deploy to achieve the same. Bitbucket and Jira in the cloud are very cheap, Teamcity – depending on the number of projects is free, as is Octopus.
In terms of Project Management there are loads – Basecamp (which I quite like), Jira, YouTrack, Ontime, Mingle
In terms of CI you have Jenkins, Bamboo, TeamCity, CruiseControl.net
In terms of Deployment – Octopus Deploy, Redgate Deployment Manager
In terms of Source Control tools you have a choice of lots:
Git – Gitlab, Bitbucket / Stash, Github
Svn – UberSvn, ProjectLocker, VisualSVN Server
Other – SourceAnywhere (not my choice ;)), Mecurial based solutions.
It is my belief that choosing TFS as the main platform to aid a Sitecore team to deliver their solution will inevitably cost productivity.
Sure – there are workarounds for some of these issues, but the fact that I have to go looking for them tells me everything about a tool set that (for the most part) I want to enable development and get out of my way.