次の方法で共有

What Compiler Do You Use?

  • [アーティクル]

This is a common question I get asked at a lot of conferences: users are always interested in what tools we use internally.

The answer is complicated.

First: there is no one single version of the compiler which is used by every team at Microsoft. Each team is free to choose which ever version of the compiler best suits their needs. For a lot of teams this is a previously released version of the product: some teams use the compiler that shipped with Visual C++ .NET 2003 (AKA Visual C++ 7.1) other teams use the compiler that shipped with Visual C++ .NET (AKA Visual C++ 7.0) some team still use Visual C++ 6.0 and I have even heard reports of a team that still use Visual C++ 5.0 (Why? I have no idea).

But for some teams like the Visual Studio team and the Windows team a previously shipped product in not new enough - they needs access to features that are not yet ready to ship: so these teams need to engage in that great Microsoft tradition dogfooding.

Dogfooding is not only a great way for these teams to get early access to the features that they need but it is also a great way for the compiler team to get our latest compiler heavily tested on some real world code: running compiler test suites is one thing (and a very important part of our testing strategy) but there is no test like being able to compile and boot NT.

How does dogfooding work: every few months the Visual C++ team decides that they want to start an LKG push - LKG stands for Last Know Good: an LKG build is a complete compiler tool set that the Visual C++ team feels is good enough to be used outside of the immediate team. The LKG process involves first picking a daily build that we feel is of a high enough quality - basically a build that passes all our front-line testing. Once we have such a build we create a branch off our main development source code control depot and this branch becomes the LKG branch. This compiler is then subjected to a full test pass and any issues that are found are fixed in the LKG branch (and, of course, in the main branch) once our QA feels that the LKG has reached an appropriate level of quality we start dropping early releases to those teams that are interested (different teams pick up releases at different times: if a team is just about to ship the last thing they need is a new compiler) these teams will build their product and run their own internal tests. Any issues they find are reported back to the Visual C++ team and if necessary the LKG build is updated. Finally whenever all the teams agree that the quality of the compiler is high enough the tools set is released and the other teams can pick it up and use it to do their daily builds.

But the story does not end there: no matter how much testing we do issues may slip through: so it is possible for a team like NT to find an issue several months after we have released an LKG: in these cases we have to track down the issue, fix it, patch the LKG and release the updated toolset.

As you would expect the most extreme dogfooders of the compiler tools are the compiler team themselves: we use tools that are only days old: yes this can have it drawbacks as the tools can sometimes become unstable but these problems are minor when compared to the benefits we get from a lot of people using the latest version of the tools.

In my next blog I'll talk some more about our internal development processes and how we try to guarantee that every build of the compiler is a high quality build.

Comments

  • Anonymous
    December 13, 2003
    One question I'D be interested in knowing the answer to, is what do you use for source code managment? I have a hard time believing that VSS is robust enough to cover your branching and scm needs.

  • Anonymous
    December 15, 2003
    I would also be interested in knowing what source code management system Microsoft uses. Like Matt, I find it hard to believe that Microsoft do not use substantially better tools than VSS.

  • Anonymous
    December 17, 2003
    The comment has been removed

  • Anonymous
    January 28, 2004
    Microsoft uses Source Depot, which is the name of a modified version of Perforce (p4)

    Very nice...

  • Anonymous
    May 28, 2004
    where can one get a copy of the Perforce compiler?

  • Anonymous
    November 24, 2007
    PingBack from http://feeds.maxblog.eu/item_736764.html

  • Anonymous
    June 09, 2009
    PingBack from http://toenailfungusite.info/story.php?id=9058