巨作：Windows 是怎样开发出来的

dalaohu

Microsoft worker Richard G Russell has revealed exactly how the company builds Windows and what it’s like to work at the software giant.

Russell penned a blog post on Sunday entitled “Working at Microsoft – Day to Day Coding“. The post details developer life at Microsoft, right down to the fact that developers use quad core 64-bit systems with 8GB RAM, fast hard drives, gaming quality graphics adapter and at least two large monitors. “Many people have three monitors, some have four. We’re moving to SSD’s,” writes Russell.

Russell also details how Windows team members code at Microsoft. “Teams are free to code in their own style. By style here I mean typographic style – where curly braces go, tab indent size, where spaces go, comment format: things that have no semantic impact. There is no draconian common coding style mindlessly forced on everyone,” he reveals.

Perhaps the most interesting part of Russell’s post is the thorough detail of Microsoft’s build process for Windows. Russell says that most Windows workers run a current Windows build. “Daily builds are almost always very stable and useable,” according to Russell. “Builds usually start about 5:00pm though teams can set their own defaults, or change it for a day. This means that a fully installable version of Windows is built from source every single night – though we pause for holidays, and sometimes if there are snow days. Builds are ready for use when we arrive for work the next day. We build four ‘flavors’ of each branch every night; x86-optimized, x64-optimized, x86-debug, x64-debug.”

Russell also details the three levels of Windows builds. “The entire build environment is checked into source depot – not just the source code. This includes the compiler, linker and other build tools. We can re-build any version of any Windows product going back to XP SP1 very easily.” Russell also shares a diagram of how code is compiled and checked into the source depot:




There are many ways to use branching, we mange them as a tree.   The WinMAIN branch is at the top.  “Official” builds of Windows are built from WinMAIN. This includes the RTM, CTP and BETA versions.

Underneath WinMAIN are aggregation branches. These correspond to large team’s of developers.    We call these L1 branches.

L2 branches corresponds to teams – generally 60 to 90 people including developers, testers and program managers.

L3 branches correspond to feature crews.  A crew is usually 3 to 10 people that collectively own a feature, or set of features. My team of six developers, four testers and three PM’s  (in addtion to our three leads, development, PM and test) has its own L3 branch.

WinMAIN, L1, L2 and L3 branches are all managed by a central build team.  There are dedicated build servers for each branch.  Crews can create L4 (or even L5) branches, but they must mange these themselves (its not difficult or time consuming).

Russell is a self described hiring manager at Microsoft, in the Windows organization, having worked at the company for over seven years

乱码

顶一下！！

等unix/linux那边的人来拆台

charmer

Dan.and.Andy

讲了半天原来windows的开发就是build, 也没有几次kernel的重构. 总算明白了, 美国本土那里的coder就是包装工. 怪不得360发现了存在于windows系统23年之久的"长老"漏洞.

mylt

linux 的那个图看得好复杂

yesngo

可见linux不如windows

大饼

linux的device driver是做的非常滥

flyspirit

有意思，这篇文章好像已经被删除了。 还好google能找到cache的版本。 不知道发生了什么情况， 大老虎知道吗？

dalaohu

原帖由 flyspirit 于 2011-3-2 22:50 发表
有意思，这篇文章好像已经被删除了。 还好google能找到cache的版本。 不知道发生了什么情况， 大老虎知道吗？

真的啊。。。那人的博客已经被封杀了。 一定是老大怒了。

dalaohu

他有几篇微软内部开发的文章全都没了。。。

flyspirit

是啊， 本来是一个系列的， 你有保留马？其他几篇貌似找不到。

Richard G Russell暴太多内幕了。会不会因此而被fire呢？

dalaohu

原帖由 flyspirit 于 2011-3-2 23:32 发表
是啊， 本来是一个系列的， 你有保留马？其他几篇貌似找不到。

Richard G Russell暴太多内幕了。会不会因此而被fire呢？

我也没有啊。。。后悔啊。。。被和谐的东西都是好东西啊。。。

flyspirit

找到另一篇了：Working At Microsoft–20% Time and Prototypes， 也是cache的版本。

dalaohu

原帖由 flyspirit 于 2011-3-2 23:36 发表
找到另一篇了：Working At Microsoft–20% Time and Prototypes， 也是cache的版本。

对， 我前2天也读到了。 MS可能要划20%时间全民开发WP7 APP

你能贴一下吗？

flyspirit

Jibe!
Working At Microsoft–20% Time and Prototypes
with 4 comments

I quite often see assumptions on the inter-tubes that writing software at Microsoft is a mind-numbingly boring, tedious, manual, excruciating, soul-crushing bureaucratic exercise. This couldn’t be further from the truth – especially in Windows.  Google is famous for their 20% time policy.  Microsoft doesn’t have a similar policy, but how we do things may be even better.

You can find the full series list here.


--------------------------------------------------------------------------------

Much has been made about Google’s 20% time for developers.  If I understanding things correctly, people get about 1 day per week to work on things they feel are important. This is pretty cool.

Of course, Microsoft does not have the same policy.  Much has been made about this as well.

What I don’t think has been well explained is that Microsoft’s approach – while maybe not as sexy, and certainly not highly publicized – may actually be better.

Most product teams in Microsoft (especially the Windows, Windows Live, Office and Developer Division) work to schedules.  Meeting delivery dates is very important. This means that when we are in an active product development cycle we focus on getting our work done – hitting our dates. As you can imagine, cutting out 20% of every developers time in a product cycle would be pretty detrimental to the schedule – it would push things out considerably.

But, when we are not focused on finishing a coding, integration or stabilization milestone, we very often have time to work on 20% kind of things – often way more than 20%. We call this prototyping.

It is quite common for prototype code to productized and used in products. in fact, we usually use our production coding systems for prototype work.   My team writes all our prototype code pretty close to production quality.  We don’t hack it.   Ad-hoc hacking just isn’t any faster than writing code well.

Prototypes are often rolled out to all the systems in Windows for testing. We’ll instrument these prototypes and collect data on them. Our regular systems catch problems like crashes and hangs

I’ve done quite a bit of prototyping. So have many others I know. This is true for minor things and some big things. For example Superfetch was heavily prototyped. So where some key cold boot optimizations, and a lot of our work on the xperf family of performance tools (and this).   We’ve also prototyped internal things like telemetry processing tools, lab automation systems, and general helpful developer tools.

This is also time where we work with Microsoft Research to productize their work.   We have quite an active program to do this – MSR and product teams work very well together.   My team has an MSR project already queued up.

We could not have included many features in Windows without considerable prototyping time. Prototypes are most often the idea of a single person, or a small group of people. Program mangers often come up with great prototyping ideas. Prototyping ideas almost never come from management saying “Hey guys, go prototype this thing” (but that does happen sometimes).

In addition to prototyping features, there is a rich culture across Microsoft of building helpful software and making it available to other people in Microsoft.  We have quite a nice in-house system for sharing tools and code.   Our external CodePlex.com site is based on the internal system.   This all started out as ad-hoc stuff.

If people don’t want to spend time prototyping or writing tools, they can simply use that time to teach themselves new things.  For example, my WPF posts were done based on such time. I also taught myself MVVM.  This was really handy because all our current projects use WPF and MVVM extensively.  This time helped me prepare for our current projects well.  Note, this wasn’t time I spent at home.  This was all done at work.

In summary, there are times in our product cycles when people have quite a bit of discretionary time.   Way more than 20%, often close to 100% for weeks. This is deliberate.  We use this time for prototyping, thinking, experimenting and learning. Many excellent product features come directly out of this fruitful time and efforts.  Most of this work is done at the grass roots level and determined by individual contributors or small teams of people with like interests and passions.   This is not a new thing.   The Windows organization has worked like this for a long time.