Automating .NET builds – It’s not all about TFS

There is another way. You have an option. Just because you are working in a .NET shop does not mean you are locked into using TFS.

In fact in many ways you would be better to break the shackles of TFS. It’s easy to use Jenkins for Continuous Integration and Git for configuration management with.NET.

This essay will not try to detail all the reasons why TFS is bad. Google “TFS sucks” and you’ll get “About 200,000 results”. Pages like this, this, and, I can’t resist, this do that job nicely.

Rather, this piece will discuss:

• Prevailing attitudes to looking outside the box.
• The current industry adoption of Jenkins and (relatedly) Git.
• Why Microsoft has (again) lost the war and is capitulating to the Open Source community.

While in the open source community there is a constant curiosity to try out new things and apply technologies in ways they weren’t initially intended, the prevailing attitude to trying something that does not have the Microsoft holy seal of approval seems to be “But we’re a Microsoft shop”. Hands up if you’ve experienced the same response.

It is probably unsurprising then that the penetration of Jenkins into the .NET community is shallow. I am encouraged however, as the author of the JenkinsHeaven blog that over 4000 people a month are interested in using Jenkins to do .NET builds and that the current situation may be changing. Go see those posts for the how-to of Jenkins and .NET.

Microsoft capitulates (again)

Rather than "All things to all people", it is probably more apt to say of TFS: “You can’t fool all the people, all the time”. In short, TFS tries to do too much and as a result is not best-of-breed at anything. I give no credence to the argument that TFS is an Application Lifecycle Manager. If anything this only proves my point. At a high level, Microsoft seems to have dropped the Separation of Concerns or Single Responsibility Principle (take your pick) ball when it comes to TFS.

Cracks (or is it hypocrisy?) started to appear about a year or so ago when CodePlex migrated all their repositories to Git….”Say what?” you say. Yes indeed! CodePlex migrated all their repositories to Git. In other words, CodePlex is an interface to Git.

Why should I adopt TFS when Microsoft has quietly adopted Git? Furthermore, Visual Studio 2013 has dropped the pretence and is adopting Git in a big way. All the details are here. Mendocino Triple Junction is closer to Seattle than we thought. It is with this development that Microsoft has announced its capitulation. Git has won the war and Git will rule the world.

After trying for a couple of weeks at work to integrate Jenkins into the build environment of a .NET project the piece in the puzzle that I couldn’t solve was TFS. I raised this (mainly to see if anyone else had experienced this and had a workaround). As far as I can gather the issue is with TFS, not Jenkins or the plugin. TFS does not want to play with other children.

That is why Microsoft adopting Git is a wonderful thing. It will hopefully take the TFS Source control barrier out of the Jenkins-as-CI-for-.NET-environment equation. In other words, it is my hope that this development will drive Jenkins adoption in .NET shops.

In the same way that Nirvana gave rock and roll its requisite periodic kick in the nuts, all I would say is that it is perhaps disappointing that Microsoft always seems to trail the field rather than leading the way, with a modus operandi of cherry picking 5 to 10 year old open source ideas.

Thank you for reading this far, if I have encouraged you to question the TFS status-quo in your .NET projects, then I have achieved my aim.

You may have got the impression reading this that I am a Microsoft hater. Far from it! As the Founder and Lead Developer of Full Circle Solutions, Visual Studio is our tool of choice. When it comes to writing code that is. It is worth noting at this point that before being a .NET developer, I was a Java developer. C#’s other name being “I-can’t-believe-its-not-Java”. As I see it .NET sits in the same space as J2EE and .NET is better documented and much more polished.

Visual Studio 2012 and the .NET framework are the start and end of our Microsoft tool adoption. We use Jenkins, not TFS, for Continuous Integration to ensure the quality of our product offerings. We use Git, not TFS, for configuration management.

It is due to my experience in both the Open Source and .NET world and thinking about this area while researching and writing JenkinsHeaven that, 3 years ago, I settled on Jenkins, Git and Visual Studio as the best of breed toolset. This is the direction I have selected for Full Circle Solutions.

Till next time...