Freigeben über

Size of Visual Studio

  • Artikel

 Ever wonder how large Visual Studio is? This public comment from the MSDN feedback gives some good stats:

Visual Studio is over 43 million lines of code, there are over 30 teams working on different pieces, with roughly 700 developers checking-in code to 11 different virtual build labs that are then integrated on a rotating schedule producing over 100 different builds of the product daily. In addition we have interdependencies with SQL and MSDN. When we ship an official release like a Beta or RTM (release to market) we lock down and are code complete several months before the actual release date to allow for a final test pass, to stabilize and hit stress goals, then get the best bits to fulfillment for mass production of media. Before code complete there is a long list of exit criteria for the product that must be met, ensuring all key features and scenarios meet expectations. We have customer bug exit criteria to ensure high priority issues are fixed.

We've had a very interesting challenge scaling development and testing techniques up to a product of that size. It seems like most methodologies ("You just write unit tests for everything and then you have no bugs") I hear about are really intended for about 5 person teams. If you had a unit test for every 10 lines of code, that's 4 million unit tests. That's would be a lot of unit tests to run before a single check-in.

Comments

  • Anonymous
    August 23, 2005
    I can only imagine what the situation is like for longhorn.
  • Anonymous
    August 23, 2005
    Really interesting statistics on the size of Visual Studio 2005 by Mike Stall.

    Visual Studio...
  • Anonymous
    August 23, 2005
    Are you saying that Microsoft developers do not unit test, Mike?

    Most clear-headed people would agree that unit testing is but one part of any quality assurance strategy, whether the team has 5 or 100 developers. I've yet to see anyone argue, however, that unit testing should be displaced once a project gets to a certain size.

    I'm very interested to hear how testing is done for a major Microsoft product.
  • Anonymous
    August 23, 2005
    As TrackBack didn't work:
    http://nayyeri.net/archive/2005/08/23/101.aspx
  • Anonymous
    August 23, 2005
    Impressive !
    Do you have any more detailed information about the scaling and testing difficulties ?

    Thanks,
    Bart
  • Anonymous
    August 23, 2005
    Tony - No, I'm not saying that. We definitely unit test. I'm just saying that unit test strategies for a 5 person team don't scale to 700 developer team. It's impossible to run all the tests before every single check-in.

    Testing is a major challenge opportunity for a project of this size. Testing a product like Visual Studio (and the CLR) is a lot more than just having somebody sit in front of the product and clicking buttons. There's an entire complex test stragety and we have a lot of talent in our testing infrastructure.

    For example, MDbg (an extremely extensible managed debugger written in C#) was originally done by our testing team as a way of testing the debugging services APIs (ICorDebug).

    This whole area is great blog fodder. Stay tuned...
  • Anonymous
    August 23, 2005
    Masterpages superquick / dummy guide:
    http://www.dotnetjunkies.com/WebLog/cykophysh/archive/2005/08/19/MasterPages.aspx...
  • Anonymous
    August 23, 2005
    Do the 100 builds daily mean a full or incremental build. I guess a full build will take a lot longer until it is finished. When you change some central library which is referenced by many others targets a full build would be the only thing to go or do you have some smart strategies to work around such things?
  • Anonymous
    August 23, 2005
    Akraus1 - I don't know for certain. There's a whole team just running the builds.
    Many of them are indeed full builds. Others do full builds of part of the tree and piece that together with binary drops from other parts of the tree.

    We generally avoid incremental builds for official daily builds:
    a) there's enough daily churn that an incremental build likely degenerates into a full build.
    b) incremental builds have a higher risk of an error in the build infrastructure. (eg, bad dependency anaylsis resulting in something not gettint rebuilt)
  • Anonymous
    August 23, 2005
    just something about testing of Visual Studio.
    Have a read of my latest post, there is a link that will tell you how many testers there are, and how MS tests.

    It will even tell you wich software is used for bugtracking etc.

    http://bloggingabout.net/blogs/wellink/archive/2005/08/24/9068.aspx
  • Anonymous
    August 24, 2005
    The comment has been removed
  • Anonymous
    August 27, 2005
    At this point, I've got what seems to be an endlessly long list of things I'd like to eventually blog...
  • Anonymous
    September 02, 2005
    Visual Studio to duży i skomplikowany produkt. Na łamach swojego bloga Mike Stall przytacza kilka liczb, które pomagają to sobie uświadomić.
  • Anonymous
    September 02, 2005
    Visual Studio to duży i skomplikowany produkt. Na łamach swojego bloga Mike Stall przytacza kilka liczb, które pomagają to sobie uświadomić.
  • Anonymous
    September 02, 2005
    Visual Studio to duży i skomplikowany produkt. Na łamach swojego bloga Mike Stall przytacza kilka liczb, które pomagają to sobie uświadomić.
  • Anonymous
    July 15, 2006
    Visual Studio is over 43 milion of code , 30 teams are working on it and … Read more I enjoy this
  • Anonymous
    August 21, 2008
    Work at home moms. Wahm com the online magazine for work at home moms.