Ars Technica's Peter Bright digs into the challenges of developing the Windows OS, in an environment with 4 million commits and 10 million work items (current counts on the march toward releasing Windows 10 1709 late last year). A fascinating investigation of Git in the context of Visual Studio Team Services for an astonishingly large code repository and file collection.

Building Windows: 4 million commits, 10 million work items

Microsoft talks about some of the work it’s done to move Windows development to VSTS.

PETER BRIGHT - 3/12/2018, 2:42 PM

Microsoft's switch to using Git as the version control system for Windows' development has resulted in many challenges. Git wasn't really built for a 300GB repository with 3.5 million files, and the engineering effort to make Git scale in this way continues.

But in adopting and developing what the company is calling One Engineering System (1ES), the Windows and Devices Group (WDG) has adopted more than just Git; the group has also adopted Visual Studio Team Services (VSTS), the company's source control, item tracking, integration and testing system, and with VSTS a more integrated, devops style approach to developing. Git is an important part of this but far from the whole story. Microsoft wrote today about some of its experiences using VSTS, including some of the problems the scale of the operation has caused.

The adoption of VSTS features and devops practices isn't uniform across WDG. Continuous integration and continuous delivery make sense for some parts of WDG—online services are an obvious example, and even some of the apps in the Microsoft Store could qualify—but they're less applicable to the core Windows operating system itself. Nonetheless, the company has worked to standardize practices that are common to every component.

The Fall Creators Update (version 1709) is a good demonstration of just how big an operation Windows is. That update included some 4 million commits, grouped into half a million pull requests to get those changes incorporated into the main Windows code. Each pull request—a group of changes batched together representing a new feature, a bug fix, or similar—is a request to merge some changes into the main branch, with those changes merged into the most recent version of the main branch. If two pull requests are accepted at the same time, they'll both try to merge into the same current version, so one will succeed and the other will fail; it will have to be retried against the new current version that includes the accepted request. Done naively, this creates lots of wasted work for each pull request.
See the rest of the story at Building Windows: 4 million commits, 10 million work items | Ars Technica.