Microsoft Branching Strategy

We decided that each team would get its own feature branch, each feature area (multiple teams) would go up to an aggregation branch, and those would lead up to the final main branch. (As such there’s now north of 100 branches in tiers, leading up to 6 aggregation branches.) Teams were free to choose how many sub-feature branches they wanted, if any, and they were free to choose how often they wanted to push up their changes to the aggregation branch. As part of the reverse-integration process, various quality gates had to pass, including performance tests. Due to how comprehensive those gates ended up being, this would take at least 1 day to run, plus perhaps 1-2 days to triage issues if any cropped up; so there was a possibly considerable cost to doing an RI in the first place. However, these gates were essential in upholding the quality of the main branch, and had they not existed, the OS would have never shipped.

the challlenges of the windows scm have always intrigued me. years ago, a paper by markl was leaked – nothing since. so it’s good to hear what is going on in current windows builds.

Leave a comment