tfs - Team Foundation Server 2010 branching setup -
we're setting brand new tfs 2010 server, without having used tfs before (or, frighteningly enough, no other central source management system). here's general structure our small team (of 6-7 programmers) talked setting up, , i'm curious, based on others experience working tfs, if idea or not (these names descriptive , not we're planning use):
$/ our organization's collection/ .net technology projects/ class libraries projects/ project 1/ project 2/ project 3/ etc.../ asp.net projects/ project 1/ project 2/ project 3/ etc.../ windows workflow foundation projects/ etc.../ wpf projects/ etc.../ other non .net source code/ sql/ server configuration/
(and on)
will regret structure after year of using it? application span many parts of structure - problem manage?
at level set release/main/dev branches?
thanks input , guidance!
plan now. branch when necessary.
with team has never managed branching/merging, wholly recommend keeping simple possible start (meaning, forget branching short term). after having converted our source vss tfs2010 , implemented branch quality strategy team of similar size similar experience levels, recommendation this:
do not implement branching strategy until need it. can branch once determine necessary. go ahead , bring projects tfs source control , make sure comfortable software , teamwork necessary keep stable.
in meantime find members of team interested , give them time research, train, test, , practice on parallel or simplified instance of codebase. need practice creating projects, branching , merging in situations mimic deployment process; need time communicate rest of team fine tune processes , document them; need willing resource other members of team learning curve flattens out. way have team members prepared , confident step , implement chosen branching pattern.
you not want jump branching strategy before determining need it. there large amount of administrative overhead involved plenty of perils.
with said:
i don't think have trouble managing have there once start branching accommodate need. key here make sure don't over-architect , complicate management of source/deployment. know structure of tfs reflected in local file system / workspace.
we created separate team project each independent solution or group of related reused libraries. in 1 case grouped set of highly dependent solutions under single team project - large multi-application intranet portal deployed @ once. doing allows keep deployment , source management simple. here @ our branching structure 1 @ high level:
this 1 large project many sub-projects. every branch complete copy (just difference/versions stored on server). there large number of team projects above , below 1 in collection , looks lot list top.
the final answer depends on interdependency, structure, , deployment strategy of applications. have specific concerns regarding structure there?
Comments
Post a Comment