Software Engineering, Project Management, and Effectiveness
How do you share code in Team Foundation Server? That's what our team is working through at the moment. We're looking at what's working, what's not working, and what should customers be doing.
Here's how we're basically thinking about it so far:
Here's what seems to be our emerging guidance:
The problem with workspace mappings is that they're developer specific. Each developer will need their own mapping. You'll also need to lock down permissions to avoid accidental changes. Branching has the advantage that you can be explicit about taking changes, so you have stable builds but with the overhead of merging. You can branch within the same project or cross-project. A separate project might make sense if you have multiple projects consuming the code.
I need to still look across more customer sets, but so far I mostly see binary reuse.
I'm particularly curious in any lessons or insights those of you would like to share. I think this is an important area for effective source control practices.
We are using binary sharing (using a common library for multiple projects). That combined with TFSIntegrators great "dependency replication" feature works really great for us.
In short: When the librarys "Release" - build is successfully built the "dependency replication" feature automatically checks in the resulting .dll in our depending projects "\trunk\dependencies". And that is causing a CI-build of the depending project to be started immediatly and there by giving "instant" feedback if something has been broken by the library changes.
More info on TFSIntegrator here:
We use a combination of these approaches. For all Third Party components we use binary sharing since these are fairly stable.
Within the project itself we have multiple solutions and these are shared via workspace mapping unless part of the team needs to be isolated then we make a branch.
There is one other case where we use binary sharing and that is because the other project is still on .NET 1.1 so that team builds their assemblies and checks them into another project source control tree in an assemblies folder.
We assembled a solution which resembles a lot the solution you are offering and supports paraller development:
I agree that the combination of multiple braches and a workspace mapping manipulation is sometimes complicated to handle, but it gets the work done :)
The Sandcastle Blog on Announcing March 2007 Sandcastle CTP Technical Refresh. J.D. Meier on Code...