构建Windows是一项庞大的过程

微软转向使用Git作为Windows开发的版本控制系统给自己带来了诸多挑战。Git并不是真正为拥有350万个文件的300GB存储库构建的，而以这种方式进行Git扩展的工程设计却仍在继续。

在采用和开发公司所称的One Engineering System（1ES）时，Windows和设备部门（WDG）采用的不仅仅是Git; 该组织还采用了Visual Studio Team Services（VSTS），该公司的源代码管理，项目跟踪，集成和测试系统，以及VSTS更为集成的开发人员风格的开发方法。Git是这个的重要组成部分，但远非全部。微软今天写了关于使用VSTS的一些经验，包括操作规模造成的一些问题。

在WDG中采用VSTS功能和devops并不统一。持续集成和持续交付对于WDG在线服务的某些部分来说是有意义的，甚至Microsoft Store中的一些应用程序也可以获得资格，但它们不太适用于核心Windows操作系统本身。尽管如此，该公司一直致力于对每个组件的标准化。

Fall Creators Update（版本1709）很好地演示了Windows的操作有多大。该更新包含大约400万次提交，分组为50万次pull请求，以将这些更改合并到主Windows代码中。每个pull请求，一组代表一个新功能，bug修复或类似功能的更改组合成一个请求，将一些更改合并到主分支中，并将这些更改合并到主分支的最新版本中。如果两个pull请求同时被接受，它们都会尝试合并到当前的版本中，这样一个会成功，另一个会失败; 它将不得不针对包含已接受请求的新当前版本进行重试。天真的说，这会为每个pull请求创造大量浪费的工作。

在开发人员数量正常的典型项目中，pull请求的数量通常很低，以至于没有人试图同时合并两个请求，所以这种情况几乎不会发生。事实上，只有一个人接受pull请求的情况绝不会发生。但对于Windows来说，大量的pull请求和更改意味着主分支几乎总是被更新，这使得两个pull请求更有可能尝试同时合并。因此，pull请求即使在被接受后也会失败。为了解决这个问题，微软添加了一个排队系统以便接受的请求被自动顺序执行; 他们不会相互竞争，系统可以削减浪费的工作，这是一个天真的系统否则必须做的事情。

这对于1ES来说是一个反复出现的问题：对于小型团队来说很好，对于7000名开发人员和4000名设计师，项目经理以及在WDG内部工作的服务工程师而言，产品就变得无法使用。再例如，常规VSTS使用用户名下拉框将工作项目分配给人员。当一个项目只有少数开发人员时，该系统运行良好，但微软在VSTS中总共拥有大约80,000个帐户，这些帐户太多而无法在单个下拉列表中列出。

公司有很多工作项目。微软的做法是将工作项目用于一切; 例如，错误和新功能都是工作项目。从历史上看，该公司提供了广泛的内部访问错误跟踪功能，但跟踪新功能更加不透明，仅对于从事特定功能的团队或部门才可见。使用1ES时，这些内容全部记录在VSTS系统中，具有全公司范围的可见性和总共约1,000万个工作项目。

通过这种改进的可见性，可以创建交叉划分依赖关系，以便例如可以将Visual Studio或Office功能设置为依赖于Windows功能。这些项目的进展情况也可以跟踪，以确保在正确的时间发货。在1ES之前，该公司有五种不同的方式来跟踪这些依赖关系。

进入1ES的工作不仅涉及为Windows开发构建通用系统，还涉及这些进程的常见过程和命名。以前，不同的团队可能会使用术语“错误”或“问题”或“缺陷”，并且在处理时，这些错误可能是“完整的”或“完成的”或“关闭的”，并具有处理它们的不同工作流程。术语和流程目前正在标准化，从而实现更好的报告和更容易的数据流之间的通信。

微软使用WDG在Git方面的经验来对开源软件提出修改建议，并且在过去的一年中一直致力于将这些改变融入Git本身。适用于VSTS的缩放工作也是如此。例如，WDG希望能够创建VSTS数据档案，此功能是一个很有用的功能，并于2016年作为开源VSTS扩展发布，用于VSTS帐户之间的归档和数据迁移。