MSFT Wants Me To Use Team Foundation Server

But what if I don't want to use it? I am sure TFS is a lovely piece of infrastructure, but I have had a heckuva time installing it. After numerous attempts on a spankin' new disk, I still cannot get it to run. I don't claim to be a MSFT Products guru, so maybe I am just being a dork, but anything that is that hard to install is a little off putting, at best. Am I off base? Maybe someone can set me straight on what I am doing wrong. Someday I'll get it installed and then I can try it out. (For the record, I am hung up on the piece which requires the SharePoint persistence to be set up a certain way, but I cannot seem to make the SharePoint installer do the right thing so I need to pursue that next.)

My philosophical bent right now is to use continuous, automated integration, test-driven development (TDD), and a strong IDE. Visual Studio (VS) is a strong IDE you bet; maybe the best ever. My shop however, uses TDD, StarTeam for source control (not SourceSafe), and centralized, continuous build with CruiseControl.net. These things just don't seamlessly integrate with VS. Even with TFS, the unit-test support for TDD is pretty weak. I know MSFT is working on that and we can expect them to get it really right in another two releases. Because there is a StarTeam plugin for VSS which works pretty well, and a nice NUnit wrapper called TestRunner from Mailframe.net that lives in the IDE, we are partly there. But to get the continuously integrated warm fuzzy I seek? So I tell my boss that we can no longer use TDD, StarTeam and we can no longer have continuous integration unless we switch to Team Foundation Server? I don't think so. I have the goal of creating a nice, TDD-friendly, continuous integration framework that isn't annoying for developers to use. This is tricky, and I'll post some various aspects of this over time to show how it can be done.

The good news is that MSFT knows that there are 5 or 10 people in the world who will, for whatever wacky reason, choose not to use TFS. In fact, IMHO, in order to create a platform for team development (TFS) such that it could support current best-practice development, MSFT had no choice but to improve their fundamental build technology. The venerable nmake finally ran out of steam. A key technology here is MSBuild, is delivered as part of the .NET 2 distribution—not even an IDE feature but used by the IDE anyway. I am happy about this because they did such a nice job with MSBuild that I would say it's useful beyond just building DLLs and such, but that is an essay for a different day.

So just as an overview, let's consider in some more detail what the players are:

• MSBuild and Project files (*.csproj): Automatic builds individual developers must make EXACTLY the same build. Historically in MSFT environments this is tricky because the IDE does build in some magic way; thus do you really know what bits in are in the build and how they got there? Was there some goofball compiler flag introduced in your "production" build that no developer ever saw (and thus didn't test against)?
  
• CruiseControl.NET: Continuous integration which builds and sends scandalous emails to whomever was sloppy enough to break the build for whatever reason.
  
• StarTeam for source control: I don't use Visual Source Safe. Shocking! Subversion, StarTeam, PerForce, they all work great and have each their own annoyances. Using something besides VSS (much less TFS) shouldn't prevent me from setting up my build environment My Way.
  
• NUnit : TDD requires that I have test code and support as part of my regular IDE "air". Test code is written at the same time as application code, so I need to partition my test code from my production code but still be able to work with the test code in the IDE environment without having to think about it. I want green bars during TDD, and TestRunner from MailFrame.net (among others) provides that. [Cautionary note: the current version of TestRunner has exhibited some behavior different from what executing test DLLs with nunit-console.exe. In particular, the console run of the tests highlighted the fact that test B was expecting an object instance reference created in test A. This is pretty basically wrong from a test-development perspective, but the point is that TestRunner's wrapper on nunit didn't see it. I recommend using nunit-console as the final word, especially because TestRunner's installation uses a particular version of the nunit DLLs.]
  

That's the basic view of the stack, and further posts will elaborate on how exactly to set these up along with a sprinkling of what I believe to be best practices.