Funk legend Rick James passed away at age 56 last week.

http://www.msnbc.msn.com/id/5625044/

Please join me in a moment of silence to remember the Super Freak of Funk…

Developer Division VBL (Virtual Build Lab).

The concept of Virtual Build Labs is replicating the build process across several identical source code branches that are folks of the Main build lab, and assigning developers checkin permissions to one of the branches. Instead of a large development organization stepping on itself to make checkins into a Main source branch, the developers are grouped and assigned to make their checkins to a fork of Main. The checkins from each fork of Main are built and integrated on a regular schedule. This model is very scalable and can facilitate a large development organization to work on a single release (Windows XP and W2K3 was built and shipped using the VBL model).

The Developer Division's implementation is as follows:

Our Main branch stays pristine - the forks under DDMain must meet a criteria (such as building without errors and passing test suites) before integrating.

We have 3 primary VBL forks under DDMain that the vast majority of the Developer Division checks into: VBL21, VBL22 and VBL23. We have others, but for the sake of simplicity, this discussion will focus on the three primary VBLs.  Once I figure out how to post a .gif to this blog, I'll include one that displays the DevDiv VBL model.

We have grouped the teams that make up the .NET Framework and Visual Studio in each of these branches. VBL21 and VBL22 are made up of teams that have tight interdependencies, while VBL23 has a mix of teams with loose interdependencies. We build out of these forks every day, as well as run test suites everyday. One VBL integrates to DDMain each week, and after Main builds successfully, we integrate down to the other two VBLs. For example, VBL23 is scheduled to integrate to DDMain this week. Once it builds without error, passes all test suites, we'll integrate the VBL23 source to Main. Once Main builds without error and passes all test suites, we'll integrate the source down to VBL22 and VBL21, and start the cycle over again - VBL22 is scheduled to RI to Main next week.

In my next blog, I'll go into more detail as to the daily and weekly operations in a VBL fork (VBL22 specifically), as well as start into VBL terms, such as reverse integration, forward integration, as well as whole host of acronyms.

Release Manager.

'The only one on the team with an actual "release" title. In the simplest statement, Scott is responsible for the movement of the ‘bits’ thru the system. Scott manages the flow of code thru the division'. That's entirely true, I am the only individual in the Developer Division Release Team with the title Release Manager and I am responsible for the integration of bits around the division via integrations through the VBLs. I own the VBL processes, create the integration schedule, and have a hand in anything related to the Developer Division Virtual Build Lab. I do appreciate my hiring manager's foresight in labeling my position as Release Manager, not only because no one else has the title, but also because I do manage the daily release of bits out of the build lab. Furthermore, I certainly get feedback when something goes wrong in any part of the VBL process and bits aren't released on the drop servers.

-Scott