Software Engineering, Project Management, and Effectiveness
We've used TFS for more than a year, so it's interesting to see what we're doing in practice. If you looked at our source control, you'd see something like the following:
+ Project X version 1+ Project X version 2- Project Y |----Branches |----Releases |----Spikes |----TeamStuff |----Trunk |----Build |----Docs |----Keys |----Source |----Tools
While there's some variations across projects, the main practices are:
I'll be taking a look at how customers and different groups in Microsoft have been using TFs for Source Control. If you have some practices you'd like to share, I'd like to hear them. Comment here or send mail to VSGuide@microsoft.com
I must be on a little patterns & practices benge right now now as this is my third post in the past
I always tell folks one of the few places I'd probably be really hearily enticed to work within Microsoft...
In the past I've used the following source control structure:
+ Project X
+ Project Y
- Project Z
|-- Root Namespace
|-- Win or Web
Just another idea...
I wanted to clarify a point of confusion that JD and I discussed in the hallway on Friday.... shelvesets.
We use shelvesets for putting trunk work on hold or for sending it to someone else. We don't use it for branching. We don't use it for CTP type stuff.
For example, suppose I am working on my task for the day but am not yet finished when I nasty pri-1 bug comes in that needs my attention. I don't want to check in this code, it is broken. So I shelve it and revert back to the trunk or the tag/label where the bug exists. I fix the bug (either in a branch if it was from pre-trunk code or in the trunk if it is there) and check in the code.
Then I can return to my shelveset and keep on working. Easy as pie.
We also sometimes use shelvesets when we need to send work in progress to someone else on the team... either for review or because they are taking over the work from you.
Shelvesets are nice, but it is important to understand what they are for.
We're in the process of converting a large SaaS web application to TFS, and we're a bit overwhelmed at the lack of direction or guidance. I'd love to see any examples of TFS source control structures for large web applications. I'd also like to see suggested practices for shared code, such as any common, business, or data tier projects used by multiple web/win projects. I've yet to find any guidance for shared code, yet n-tier architecture is all about shared code. I'd think there would be a lot of detailed, real-world examples on how to work in this type of environment.
We have incremental releases, so multiple team projects per "release" doesn't sound advisable in our situation. We want to use Scrum and have each incremental release (sprint) carve some work items out of our massive backlog of features to be implemented. Basically, I'd like to see a solid example of any "best-practice" web application with a reusable layer or two mapped into a fully-working TFS source control structure.
Is it approriate ( or even possible ) to use shelvesets as a sort of promotion branch? That is have a main build that builds trunk ( or a branch ) and then have another build that builds that trunk ( or branch ) including proposed solutions ( shelvesets ). Then when they are unit tested and approved they just get unshelved and committed to the main trunk ( or branch ).
Revolving credit tends to be the most prevalent among Americans
Could you please expand on the Branches and Releases folders? I would like to see what their sub-folders look like and how you name them.