构建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帐户之间的归档和数据迁移。

  • 发表于:
  • 原文链接:https://arstechnica.com/gadgets/2018/03/building-windows-4-million-commits-10-million-work-items

扫码关注云+社区

领取腾讯云代金券