Number of Projects Growth
I've been thinking a little bit about what it would take to support a single centralized TFS configuration for an environment like my current workplace, and there's one thing I'm curious about.
Our environment really wouldn't be too taxing in general: Around 150 users (tops, and that only in a few months), and projects are generally not too big.
However, the thing that I'm curious about is how the number of Team projects might affect performance and how it might affect server operations. For example, those 150 users might be working on, say, 15-20 team projects at a time, since we work on custom software for several clients (and sometimes multiple projects for a single customer). Now, projects are not very large, normally having each one around 3-10 people tops and, say, most lasting around 6 months, ocassionally longer than that.
The thing I'm somewhat curious about is how, as the number of projects grow (say, projects are being closed and new ones created), how performance might degrade and operations complicated (say because of backup time). I'm assuming we might create, say, 30-40 projects a year.
So far, I haven't seen tools to "deprovission" a project so that we could move it to an offline storage and possibly bring it back up in, say, case of an emergency or a project restart... are there actually any facilities for that, or is the assumption right now that once a project is created you live with it forever? :) (this can be done right now fairly easily with SourceSafe using the archive facilities, though they are not exactly very reliably).
Any ideas?
Buck,
That's actually exactly what prompted me to ask the question :)
It seems to me that the data that has been used in the current load tests is more focused on having a fairly constant amount of team projects that are large and on which people work for a long periods of time (years, probably), and I'm sure that's a very realistic set for most of your target customers. Am I correct in that assumption?
If so, then what I'm trying to bring across here is that I think our environment is a little different in the sense that we work with more smaller projects, with shorter cycles, meaning we grow in a somewhat different direction, and I'm curious how that might affect our planning for TFS.
One thing to think about is the granularity of team projects - in one of our team projects in our dogfood setup, we have hundreds of solutions, thousands of projects, dozens of different teams, all one team project. You can set permissions in version control with very fine granularity (you could even have different permissions on every single item if you wanted), all under a single team project. There's additional administrative overhead with each new team project (creating it, maintaining the project's group memberships, etc), so I think keeping the granularity coarser has some benefits. That said, 30-40 team projects a year should be fine perf-wise - since Buck mentioned Brian's blog post, make sure to check the comments as well where Brian mentioned that we've tested up to 800 Team Projects.
In terms of "de-provisioning" - I don't know of a tool that currently does an across-the-board backup of a team project in preparation for total removal. However, when you use TfsDeleteProject to delete it, in version control it still exists, in the deleted state (you can turn on viewing deleted items in the Source Control Explorer and see it's still there). You could undelete the contents into a new team project later on if an emergency came up and you needed access to the source again. Since it's still in version control in a deleted state, this isn't offline storage like you had asked for, but it does give you a mechanism for "removing" a team project but still being able to retrive/undelete the source code if necessary.
James,
OK, that's cool, that at least gives me a clearer idea as to how to approach it. I-m afraid consolidating multiple projects on a single team project wouldn't work for us, since we want TFS precisely for the work item tracking features (along everything else) and our projects, even if they are for the same customer, are just way too different things with completely independent schedules / life cycles, so it would be somewhat painful to put two together.
As for the tool, well, I just thing is an idea, and something that I'm sure people will eventually ask for... it might be interesting to consider it for a V.Next feature :)
