1

At my company, we have a very small (<5) team. We build internal web applications of which we support about a dozen and expect to add more.

We are setting up TFS 2010 and wonder what the best structure is? We don't work concurrently on a project, so I think we don't need branching. But do we create all our solutions under one Team Project or create a new Team Project for each web application?

We also have a few class libraries shared in all the web applications. How do we manage this? I've Googled all day on it and just gotten more and more confused.

I've looked at the guidance but it all seems pointed towards more complicated scenarios with bigger teams working concurrently.

Looking forward to any help, Richard

weegee
  • 3,256
  • 2
  • 18
  • 32
Richard
  • 5,810
  • 6
  • 29
  • 36

1 Answers1

1

I think you will find branching useful even if you have a development team of one!

Being able to try out significant code changes and being able to merge them back to the main (trunk) code is great.

In terms of shared class library projects, you can actually add them to more than one solution at any given time.

Of course changes will only happen in that project, and therefore every solution that uses them will be affected. Therefore you should set up 'continuous integration' on your build server in order to check that other solutions are not adversely effected.

  • 'continuous integration' got a lightbulb over my head, thanks :) What about having a separate team project for each web application versus one team project with all the solutions within? Big decision I'd hate to get wrong. – Richard Nov 25 '10 at 06:10
  • You probably want to get a few different opinions first, but if I was in your position then I would have everything in one Team Project to start with. If you found that to eventually be too unwieldy, then you always have the option of creating new Team Projects and migrating some of your solutions to them. –  Nov 25 '10 at 06:49
  • btw, a really nice feature of TFS 2010 is that it can build your solutions before allowing you to check in changes to your shared projects, and reject them if the builds fail :) –  Nov 25 '10 at 06:54