BUGBUG: poor title : scm

TFS Team Project whitepaper

Richard Berg — Tue, 01 May 2007 21:27:18 GMT

As promised, we finally have some guidance around structuring team projects. What can you do within a team project? What can you migrate between projects? Which settings are global, which are scoped only to Team Projects, and which can be broken into their own hierarchies? Doug Neumann reveals all. Here's an overview of what he covers:

What is a Team Project?

Strategies for Employing Team Projects

Strategy 1: Team Project Per Application
Strategy 2: Team Project Per Release
Strategy 3: Team Project Per Team

Providing Substructure Within a Team Project

Other Common Questions

What limits are there within a single team project, anyway? My answer has long been: almost none. Don't skim the big chart under "providing substructure" -- those are all important features we use extensively. After all, the entire Developer Division (Visual Studio, Team System, TFS, Silverlight...) works in one team project. I usually don't recommend creating a new TP unless there's a specific feature you can't get any other way.

Another rule of thumb I've used when answering customer questions is to have a one-to-one mapping between TPs and process templates. To me a TP represents not just a "collection of artifacts" but a physical instantiation of your abstract development process/workflow. Currently, if you create a new process template, you have no choice: TFS won't let you update an existing TP, apart from minor changes (e.g. uploading new work item types). More conceptually, if you're feeling like your process needs to change, it's a sign you may need to create a new TP in the future.

Perhaps more controversially, I think the relationship works in the other direction: you usually don't need more than one TP per process template. If several teams are planning to adopt the same process, they can probably share the same TP. Similarly, if you're happy with a process currently in place and don't plan to change it, you probably don't need to create another TP just because you hit a certain release milestone or finished servicing a certain customer. Again, use the extensive charts in the article as a checklist to make sure your team project can really handle this -- my guess is you'll be pleasantly surprised.

Note: all recommendations above are my own, not those of Doug, the TFS team, or Microsoft

TFS Branch & Merge whitepaper plus recommended links

Richard Berg — Thu, 22 Mar 2007 06:25:00 GMT

It's finally here! Our first real guidance on branching & merging has been posted, on a Codeplex wiki no less. I reviewed several drafts of the paper, but the real credit goes to Mario for driving our (the product group's) side of the process. Congrats to him, the UE team, and the VSTS Rangers on this milestone.

Definitely watch the recent Channel9 "Branching 101" interview while you're at it. I get asked for branch/merge guidance constantly on the MSDN forums; while there are lots of good resources on the web, the interview & whitepaper above make relevant recommendations much easier, especially for TFS users. If you finish those two and still want more, make CMCrossroad's encyclopedic Streamed Lines your next -- and probably final -- stop.

Next in the pipeline: best practices for Team Projects, headed up by the same Doug Neumann of Channel9 fame. (he doesn't have a blog, so I'm going to embarrass him by linking up his old homepage instead) What substructures can I create within a Team Project? What do the TFS Team Project limits mean for my org? Where do I put shared code? If you finished the branching docs but still had questions like these, that was intentional -- branches and team projects are orthogonal, far moreso than many people think. Stay tuned.

When your feature hits the blogosphere: SCM and the Windows Shutdown crapfest

Richard Berg — Fri, 01 Dec 2006 18:23:06 GMT

Moishe Lettvin has a great blog entry, an inside look at how a Vista feature ate thousands of man-hours on its way to the lowest common denominator. I don't mind the UI myself (and certainly won't justify Joel's histrionics with a link) but it does illustrate several common pitfalls in large-scale software development.

Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes. It should be noted too that the only common ancestor that my team, the shell team, and the kernel team shared was the root.

Well, branch integration was my feature. While my job focused more on finding bugs than architecture, you can't own branching & merging at Microsoft without learning a lot about the broader topic of Source Configuration Management (SCM). So I too feel tied to this debate, albeit for a very different reason.

The comments and trackbacks show lots of people dumbfounded at Vista's SCM practices, and not in a good way. Sorry folks -- there are plenty of things from Vista's ship cycle to complain about, but their branch strategy isn't one of them. Granularity in your source control is important for large teams, and protecting the integrity of the root with intermediate stages is even more important. Feel free to argue that the quality gates were too bureaucratic or the integration schedule too random, but they (finally) got the fundamentals right.

Could the particulars of this situation be improved? Sure. As one commenter noted, active development & testing should've been able to happen closer & closer to the root as the feature matured. Even more clearly, the teamwork between dependent feature groups left something to be desired. Much of that is political. And given everything Moishe described I don't think they could've avoiding RI/FI delays entirely. Still, the leadership should've been more willing to create "interdisciplinary" branches for features that were obviously interwoven. (I'm happy to say DevDiv is pioneering this.)