Ruminations of idle rants and ramblings of a code monkey

About Build … A Rant

As you may gather, I do a lot of work with Team Foundation Build. A whole lot. We have a defined process for our build/deploy cycle and we’ve gone a ways to automate a good bit of that via Team Foundation Build Server. That is a good thing.

And let me preface this rant a bit. TFS does a lot of things and it does them well. It does Build pretty well too (despite some issues). But the vast majority of the focus on TFS is about project management and source control … and the interaction between the two. Build is included but it’s often as an afterthought for development … usually as a validation of unit testing. This isn’t bad, but it’s incomplete. Why? Well … here’s the deal. Let’s say that you are really strenuous on project management and source control. You are religious on unit testing. You have a well-defined and honed process. What do you do when it comes time to release? Do you just shoot from the hip and build on the developer’s desktop? Or do you use TF Build without any thought to the process beyond compile-test-drop? Neither option really does justice to the work that you’ve put into process.

The more I work with TF Build, the more that I try to search the blogosphere and more for information to help, the more it seems to me that build is the single most under-used and under-implemented component of Team Foundation Server. There is a lot of focus on using TFS for project management – a good thing. There’s also a good deal on source control and Sharepoint integration. There is (sadly) pretty limited information on Reporting and, especially, the analysis warehouse – though that is relatively easily discoverable.

There is barely anything at all on Team Foundation Build. Yes, there are a couple of blogs with useful tidbits … but where is the documentation for the out-of-the-box build activities that ship with Team Foundation Server 2010? I’ve not found it, though I’ve searched and searched, which leads me to the conclusion that it just doesn’t exist. So … what exactly does a specific TFBuild activity do? I’m sure that someone at Microsoft knows but they ain’t telling. So we’re left to try to figure it out on our own. I, personally, have found that Reflector is absolutely essential to figuring this stuff out. I can only imagine how many untold hours are wasted by folks trying to figure this stuff out. Or … not. Maybe I’m one of the crazy few.

This bothers me and it bothers me a lot. First … it does seem that Microsoft really isn’t serious about enabling server-based builds for its own products. Sure, the core projects all support MSBuild but that’s about the end of it. There are still a TON of project types that integrated with Visual Studio that don’t support MSBuild … Reporting Services … SSIS … Visual Studio Deployment Projects (I won’t go there) … more. And then there are projects that integrated with Visual Studio that ostensibly support MSBuild but not in a way that is easily replicated outside of the Visual Studio environment … like on a build server. InfoPath is the first project type that comes to mind when I say this. Silverlight is another project type that comes to mind. And … since we do a lot of Sharepoint where I am, I was interested in the Sharepoint support in VS 2010 … and that it appeared to be supported via MSBuild. It was. But … try to build a solution from the command line. You won’t get your WSP packages. After much searching, I discovered that it could be done with certain properties that aren’t set by default. But I also found that this doesn’t work so well if you change the output folders - as is commonly done with TF Build. And for digging around in these project types, MSBuild Sidekick is the essential tool.

TFS 2010 Build is a huge step forward, to be sure. It offers far more easy extensibility out-of-the-box than the previous versions, which were pure MSBuild. But … it’s difficult to do little customizations for individual projects very easily with TFS 2010 Build while keeping the same process template for all of your builds, something that was easy to do with the MSBuild-based scripts. So … it’s great if you have builds that are all the same. But … when you are managing 100+ builds from projects that may (historically) span 3-4 years and where the risk for structural changes outweighs any possible benefits … TFS Build 2010 lacks a certainly flexibility that could be attained with 2005 and 2008. The ability to inherit from a base build process template would be good, but it doesn’t seem to be possible (though I may be wrong about that).

At the end of it … I do think that Microsoft could do a (much) better job providing a framework for building enterprise solutions. The reality is that a single TFS project collection may well incorporate over 100 projects. And when a single TFS server can service several project collections … well … you are getting some big numbers there. The kind of numbers that I’m looking at right now - 500+ projects with at least 4 project collections in the relatively near term – make it essential that we have a single, solid framework for build in place. And, since there are changes to the build/deployment process that need to be distributed globally, the default method of using Build Templates for each individual project simply doesn’t cut it. Right now, I have my template in one place and add it to each project … but there isn’t a way (documented, at least) to have this added as a part of the project creation process – unless you add an extension to the New Team Project wizard.