The Visual Studio and CLR teams are huge. If we were to all develop on the same code base simultaneously, we’d kill a lot of time because instability caused by one team’s changes would affect the whole project. To remedy this, groups of developers develop against a specific “virtual build lab”.
There’s multiple virtual build labs, thereby allowing teams to develop against a code base without worrying about changes from other teams affecting the stability of their code base. Periodically, each build synchronizes its changes with the “main” build lab. This is when:
- The main code base picks up your build labs changes
- Your build lab picks up changes from the other build labs
The frequency of these integrations is on the order of a few weeks. See the release_team blog for more specific details of the process.
Conceptually, this Virtual Build Lab system works fairly well. However, sometimes you absolutely need a change from a team that’s in another build lab. In order for this to happen, both you and the other lab’s code have to be synced against the main build lab.
The upshot is that sometimes a fix made by one team won’t be propagated to another team’s code base for quite some time. Currently we’re waiting on some stack walking changes made by the CLR team a long time ago. The way around this (if you’re lucky) is to take just the changes you need from the other build lab’s code base and integrate then into your build lab. Often times though, a change can’t be confined to a small, reasonable set of files.
I can’t help but wonder: Is there some better way of doing software development on massive projects with many teams? Specifically, is there a way of getting important changes to the right teams faster, while not compromising the overall stability for all teams?