2022年1月4日整理发布：微软转向使用 Git作为 Windows 开发的版本控制系统带来了许多挑战。Git 并不是真正为拥有 350 万个文件的 300GB 存储库而构建的，并且以这种方式使 Git 扩展的工程工作仍在继续。
但是在采用和开发公司所谓的单一工程系统 (1ES) 时，Windows 和设备组 (WDG) 不仅仅采用了 Git;该集团还采用了 Visual Studio Team Services (VSTS)，这是该公司的源代码控制、项目跟踪、集成和测试系统，并采用了 VSTS 一种更加集成的DevOps 风格的方法来开发. Git 是其中的重要组成部分，但远非故事的全部。微软今天写了一些它使用 VSTS 的经验，包括一些操作规模造成的问题。
VSTS 功能和 DevOps 实践的采用在 WDG 中并不统一。持续集成和持续交付对 WDG 的某些部分有意义——在线服务是一个明显的例子，甚至 Microsoft Store 中的一些应用程序也有资格——但它们不太适用于核心 Windows 操作系统本身。尽管如此，该公司一直致力于标准化每个组件通用的做法。
Fall Creators Update(版本 1709)很好地展示了 Windows 的操作有多大。该更新包括大约 400 万次提交，分为 50 万次拉取请求，以将这些更改合并到主要的 Windows 代码中。每个拉取请求——一组批处理在一起的更改，代表一个新功能、一个错误修复或类似的——是一个将一些更改合并到主分支的请求，这些更改合并到主分支的最新版本中。如果同时接受两个拉取请求，它们都会尝试合并到同一个当前版本中，因此一个会成功，另一个会失败;必须针对包含已接受请求的新当前版本重试。天真地完成，这会为每个拉取请求创建大量浪费的工作。
在具有正常开发人员数量的典型项目中，拉取请求的数量通常足够低，以至于没有人试图同时合并两个请求，因此这种情况几乎不会发生。事实上，如果只有一个人接受拉取请求——这是小型开源项目的常见情况——这将永远不会发生。但是对于 Windows，大量的拉取请求和更改意味着主分支几乎总是在更新，这使得两个拉取请求同时尝试合并的可能性更大。因此，拉取请求将失败，即使它们已被接受。为了解决这个问题，微软添加了一个排队系统以便接受的拉取请求按顺序自动执行;它们不会相互竞争，并且系统可以减少幼稚系统否则必须做的无用工作。
这代表了 1ES 的一个反复出现的问题：对于在 WDG 中工作的 7,000 名开发人员和 4,000 名设计师、项目经理和服务工程师来说，适用于较小团队和产品的实践变得无法使用。作为另一个示例，常规 VSTS 使用用户名下拉框将工作项分配给人们。当一个项目只有几个开发人员时，该系统运行良好，但微软在 VSTS 中总共有大约 80,000 个帐户，太多了，无法在单个下拉列表中列出。
而且公司有很多工作项目。微软的做法是对一切都使用工作项;例如，错误和新功能都是工作项。从历史上看，该公司提供了对错误跟踪的广泛内部访问权限，但对新功能的跟踪更加不透明，仅对从事特定功能的团队或部门可见。使用 1ES，这些内容都记录在 VSTS 系统中，具有公司范围的可见性和总计约 1000 万个工作项。
通过这种改进的可见性，可以创建跨部门依赖关系，例如，可以将 Visual Studio 或 Office 功能设置为依赖于 Windows 功能。还可以跟踪这些项目的进度，以确保两者都在正确的时间发货。在 1ES 之前，该公司有五种不同的方式来跟踪这些依赖关系。
进入 1ES 的工作不仅包括为 Windows 开发构建一个通用系统，还包括通用进程和这些进程的命名。以前，不同的团队可能会使用术语“错误”或“问题”或“缺陷”，当解决这些错误时，这些错误可能是“完成”或“完成”或“关闭”，并使用不同的工作流程来处理它们。在汇集不同的群体时，术语和流程正在标准化，从而实现更好的报告和更轻松的流之间的通信。
微软利用 WDG 在 Git 方面的经验提出了对开源软件的更改，并在过去一年中一直致力于将这些更改纳入 Git 本身。应用于 VSTS 的缩放工作也是如此。例如，WDG 希望能够创建 VSTS 数据存档;此功能被发现普遍有用，并于 2016 年作为开源 VSTS 扩展发布，用于 VSTS 帐户之间的存档和数据迁移。