« February 2005 | Main | April 2005 »
March 13, 2005
Code Camp Files
Thanks to all of you who attended my session on Continuous Integration for .NET. You can download the slides for here and the sample configuration files here.
Feel free to e-mail or leave a comment if you have any questions and please let me know how it turns out for you.
Posted by Mike Attili at 08:53 PM | Comments (1)
March 02, 2005
Team Build compared to CruiseControl.NET
Khushboo Sharan, the PM for build automation in VSTF, has posted a new overview of the continuous integration features of Team Foundation. Team Build didn't quite make it for the December CTP, so it's hard to make an accurate comparison to the other CI tools that I've been using.
Based on the information so far though, here are my observations on Team Build versus my preferred CI tool - CruiseControl.NET.
- Installation - Team Build will be easier to set up than CCNet, but only if you’ve already bought into the whole Team System suite. VSTS has been difficult to install correctly in the beta and CTP releases. I know that the product still needs a lot of polish and that the install will improve, but it’s still a complex, multi-tiered application. Once you're over the hump with the VSTS installation, I suspect that the Team Build configuration will be as easy as the wizard that Khushboo shows.
- Functionality - Both provide reporting of compilation errors, static analysis, unit tests, and code coverage. Both will list the change notes and authors for recent check-ins and both provide historical reports. Team Build also has reports for code churn and automatically updates the 'fixed in build...' field for defects. Both of these are hard to do in CCNet. CCNet has CCTray for unobtrusive build status reporting, support for distributed builds, and an open plug-in model for their Web Dashboard to add new tools. I haven't heard anything about an equivalent to CCTray in Team Build.
- Maintainability - Since Team Build uses MSBuild as the basis for the build process, I'm sure that any changes to the solution that you make in Visual Studio will be automatically included in your CI builds. Maintaining the NAnt script for CCNet (even using the <solution> task) is the hardest part of CI maintainence. But I know that an MSBuild block is on the horizon for CCNet, so it can also leverage these changes. I'd say maintainability is a wash.
- Compatibility - According to information from Khushboo in a recent Team System chat, the first release of Team Build will not support any other source control systems except for Team Foundation. There will be hooks for other SCC's with eventual support from vendors. But, CCNet comes with support for VSS, Perforce, ClearCase, Vault, Subversion, ... 'out of the box'. This is a significant barrier to Team Build in my opinion. If you're a VSS user, there's no reason not to change to Team Foundation. But if you keep you code anywhere else I wouldn't be in a hurry to move until Team Foundation is more mature.
- Customization - Again, Team Build will have hooks, but they won't be supported or tested for the initial version. CCNet's open source model has created a large group of contributors and the best tools and integrations have been added to the CCNet distribution.
- Price - No pricing info yet on the Team System suite, but I believe Microsoft has indicated that it's targeting development teams with more than about ten developers. My expectation is that it's going to be a tough sell (between the hardware costs, OS costs, and Team Foundation Server costs) for the 3-10 developer groups that I typically deal with. If it's true, that would be too bad because these are the folks that could really benefit the most from the out-of-the-box, pre-configured solution that Team System provides. It's easy for groups this size to skimp on proper defect tracking, testing and build management. CCNet is free to download and install. The real cost, of course, is in maintaining it and as I said above, I think that the costs there are about even.
So, on balance, I think a CCNet strategy is better for most small to medium sized development groups, especially versus the first release of Team Build. If you're starting a new, MS-only shop without the need to support legacy environments or third-party tools, I'd lean towards a VSTF/Team Build installation. But, unless the total per-developer pricing is equivalent to the current MSDN Universal cost, it's going to be a hard sell to most of my clients.
Both products are being aggressively improved. By this time next year, each should have incorporated all of the key features of the other.
And that's a very good thing...
Posted by Mike Attili at 10:05 AM | Comments (0)