Team Foundation Server Dogfooding update – May 2011
It’s been a looong time since I published a detailed look at TFS dogfooding. I used to do them every month but then the server got so big and the reports monotonous enough that I decided to stop. I’ve had a number of queries about it in the past few months, so I figured it was time to do an update.
I’ll start by talking about DevDiv. It’s more complicated than it used to be. We used to just have one TFS server for all of DevDiv and I could report one set of stats. Now we kind of have 3. Let me explain.
In TFS 2010, we introduced Team Project Collections. In many ways a Team Project collection is like a separate TFS server – it’s totally isolated in its own SQL database, etc. When we (developer division) adopted TFS 2010, we decided it was time to “start fresh”. We’d been using the same TFS server since 2004 and as these things do sometimes, it grew lint – gangly organization, extra cruft that no one actually needed, etc. Further, we made some big performance/scale enhancements in 2010 that required database schema updates and making those update to a server as big as ours was was going to take a very long time (many many days). So, we decided to start with a new Team Project collection and then just fault in the stuff that we needed – doing appropriate reorganization as we went – think of it as spring cleaning :) Of course we still keep the old Team Project Collection around and that’s where we do all of our servicing work (service pack, hot fixes, etc) for older versions of VS. However it’s not used nearly as much as the new collection is used (where we are doing our VNext work). That meant we went from 1 –> 2 collections, however, both run on the same hardware so it’s still one TFS server.
The second issue, and I wrote about this some a couple of years ago, was that the DevDiv server had gotten so big and so mission critical that we had grown to be VERY conservative about updating it. Part of dogfooding is being able to use builds that are under development but we got ourselves into the position that we couldn’t any longer due to the fact that we couldn’t risk the service interruption that bugs in intermediate builds might induce. To address this issue, last summer, we set up a new TFS server that we affectionately call “Pioneer”. On this server we have a relatively small portion of the overall DevDiv organization (maybe 350 people) doing their daily work. These teams were chosen for their tolerance for possible disruption – in most cases they are people who directly or indirectly contribute code to TFS feature scenarios and are therefore willing take some risk in order to use the latest features. We update the Pioneer server every few months.
All of this means that when I report DevDiv number, I’ll report them in 3 sets: VS VNext, VS Servicing and Pioneer. Some things, like user count, aren’t mutually exclusive (often the same people use 2 or more of the collections) and this will result in “double counting” if you just add up the numbers. However most things actually can be added to get a total number.
As you look at the numbers, a couple of things to keep in mind.
1) The VS Servicing database was around for a long time. It had many people using it for many years.
2) The Pioneer database has a small subset of teams really working in it – so it’s a fraction of the DevDiv size. Recent users doesn’t accurately reflect the proportion because it doesn’t distinguish between “light users” (someone who looks up a bug) vs heavy users (people doing checkins).
3) Pioneer is running Dev 11 pre-release bits and we have made some changes. For instance, attachment content is now included in the file count.
|Metric||VS VNext||Pioneer||VS Servicing|
|Compressed File Sizes (MB)||1,276,709||1,419,324||4,915,960|
|Uncompressed File Sizes (MB)||5,418,821||2,681,084||16,319,559|
|Users with Assigned Work Items||2,698||3,695||5,093|
|Total Work Items||200,517||650,238||927,419|
|Areas & Iterations||4,493||8,014||12,092|
|Work Item Versions||1,879,382||6,842,523||8,963,043|
|Work Item Attachments||52,542||234,074||482,249|
|Work Item Queries||26,602||21,448||125,445|
Here’s a look at the top 10 table sizes for each of the databases:
If we step back a bit and look at the broader adoption of TFS within Microsoft, we’ll see that it has continued to trend steadily up.
And here’s a simple tabular form to look at a few key metrics changing in just a few months:
Team Project Collections
Source Code Files
As you can see adoption continues unabated and we are now at about 20,000 active users (people who use it every week) using the system. DevDiv remains the
biggest single instance – MSIT is broken across many instances due to the organization of their work. We’re all ready dogfooding V.Next on Pioneer and will be looking to expand that later this year. It’s great to see so many teams and people getting value from TFS.