Dogfooding + Critical services

re: Dogfooding + Critical services

Cyrus Najmabadi — Fri, 28 May 2004 19:56:00 GMT

David: You should check the work the Team System team has been doing for VS 2005. They're working hard to make an enterprise level SCM available in the first half of 2005. You can read about it here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsent/html/vsts-team.asp

re: Dogfooding + Critical services

David — Fri, 28 May 2004 19:01:00 GMT

Does anyone at Microsoft use Source Safe? For anything real?

re: Dogfooding + Critical services

jaybaz [MS] — Wed, 26 May 2004 18:32:00 GMT

I'm not sure if I should comment on this thread. I'm Cyrus' manager, so I get to *decide* what he dogfoods. It's hard for my suggestions to get on even footing. :-)

For non-critical services:

For technology coming out of your own feature team, always use the very latest. Never older than a week. (Cyrus' feature team is the C# IDE)

For technology coming out of your product unit, use known good builds - typically a few weeks old. (Cyrus' PU is C# = { C# IDE, C# Compiler, VS Debugger})

For technology coming out of the division, use alpha+ quality releases. (Cyrus' division is Developer Devision = { C#, VB, C++, CLR, FX, etc.})

For technology coming from the rest of the rest of the company, use beta+ releases. (NT, Office).

For critical services, bump them down one level. Wait for Release Candidates of the OS for your dev machine, for Beta of the CLR, etc.

The other thing to do is make sure that teams closer to the devs are dogfooding before you do.

re: Dogfooding + Critical services

Paul — Tue, 25 May 2004 23:23:00 GMT

I'd like to see the ability to bind a test to a source control version. So I know that a particular version passed.

The biggest problem I see is that most people think VSS/Source control is Change control, it is not... Change control is a much bigger thing than just having a version of a file, it incorporates reason, context and control.

My 2 Cents...

re: Dogfooding + Critical services

Brian Schkerke — Tue, 25 May 2004 17:47:00 GMT

In terms of source code control: sounds like the best idea is to ask the team responsible. If they did introduce a breaking change perhaps you could ask them to give you a day or twos heads up, which you could use to backup the existing client and data for a possible disaster scenario. The worst change I've experienced was moving from Vault 1.2.3 to Vault 2.0.0 where the definition of label changed. It broke many installations' usage of the product, but did not cause a loss of data itself.

For the testing framework the best way to combat this is to use two testing harnesses. Perhaps nUnit and Team Services combined. More work? Possibly, but it would allow you to gauge nUnit directly against Team Services, provide valuable feedback to the Team Services team (ugh :)), and give you extremely valuable experience working within the Team Services framework itself. When Team Services was ready for alpha, beta, or prime time you would be ready with advice as to how to proceed. In situations where you must have a test and it must be reliable use nUnit or your current favorite testing harness. Struggle with the Team Service version later when you have more time.

In the end it comes down to, yes, you can dog food them but it's going to take a little extra time to safeguard your data.