I've been working at Microsoft for upwards of seven years now, and I never quite get over the awe I feel when we get close to releasing a milestone build. It's amazing to see how teams of engineers come together totally focused on resolving issues quickly to get to a stable build for our customers. The process begins weeks before we get to the final build.

The actual process starts with an idea that turns into a spec for a new feature or scenario. This is repeated multiple times across a product a complex as Windows. Then, as each team completes coding milestones, they check the code into the main build and we start building a new version of the OS. As we get close to a major release milestone like a beta or a release candidate, we go through a lockdown period where each fix or code change has to be pre-approved by a group called the Ship Room before it can be checked into the core code.

At the same time, we start releasing internal only milestone builds that are ready for deployment. These builds have been tested to the point where each engineering team is confident enough to have other employees use the builds on their work machines. Employees in Windows pick up these builds and start having interesting experiences. For example, when I loaded the latest server build today, I logged onto the machine and to my surprise, saw a desktop background picture of my children in their Halloween costumes from three years ago that I haven't seen for a couple of years. Apparently, there was an old version of my profile stored on the back-up server to the one that holds my roaming profile. When I logged onto the new build, it picked up the old profile that included the desktop picture.  While it was fun to see the picture again, I was surprised to see it. Further investigation showed that there is a glitch in the code that accesses the servers holding profiles that can cause the computer machine to pick up an old profile on log-in.

This is the time when releasing software can be fun. What a cool thing to be able to find issues and get them fixed. We are in a race now to see how many issues we can find and fix so that customers will have a great experience. It's amazing how test teams can mobilize to reproduce issues and developers can come in quickly behind to code a fix that then gets checked into the build. This process occurs multiple times across multiple teams until we release a build that can run the Microsoft business in our Microsoft IT department and all before we've released the build to customers.

I haven't forgotten the performance data I promised in the last blog. I'll have the detailed information for you soon.