软件工程之美43讲——以VS Code为例，看大型开源项目是如何应用软件工程的？
VS Code 的开发迭代过程
从开发模式来说，VS Code 采用的是快速迭代的开发模式，每四周一个迭代。那么这四周迭代的工作都是如何进行的呢？
第一周
每个版本的第一周，通常是起着承上启下的作用，一方面要准备新版本，一方面还要对上一个版本的工作进行收尾。。
第二周和第三周
第二周和第三周主要工作就是按照计划去开发，一部分是开发新功能，一部分是修复 Bug，所有的 Bug 都是通过 GitHub 的 Issue 来分配和跟踪的。团队成员每天还要先检查一下分配给自己的 Issue，如果遇到线上版本紧急的 Bug，要优先修复。
第四周
VS Code 团队把最后一周叫 End game，你可以理解为测试周，因为这一周只做测试和修复 Bug。这一周要测试所有新的 Feature 和验证已经修复的 Bug，确保被修复。同时还要更新文档和写 Release Notes。测试完成后就发布预发布版本，这个预发布版本会先邀请一部分人使用，比如说微软内部员工、热心网友。
VS Code 团队的角色和分工
从角色上来说，除了开发，还有主要有两种角色：Inbox Tracker和Endgame Master。这两种角色在每个迭代的时候是轮值的，每个人都有机会去担任这两个角色。
Inbox Tracker
Inbox Tracker 的主要任务就是收集、验证、跟踪 Bug。所以 VS Code 团队写了一个机器人叫VSCodeBot，可以帮助对 Issue 先自动处理，打标签或回复，然后 Inbox Tracker 再对剩下的 Issue 进行人工处理。Inbox Tracker 要检查新提交的 Issue 是不是一个真正的 Bug，如果是提问，建议到 StackOverflow 去问，如果是 Bug，打上 Bug 的标签，并指派给相应模块的负责人。
Endgame Master
Endgame Master 要组织管理整个迭代的测试和发布工作。Endgame Master 在每个迭代测试之前，根据迭代的开发计划制定相应的测试计划，生成 Check List，确保每一个新的功能都有在 Check List 中列出来。Endgame Master 工作就是将这些测试项分配给团队成员。最后整个测试计划会作为一条 GitHub Issue 发出来给大家审查。比如说这是某一个月的Endgame 计划。团队的日常沟通是通过 Slack，在测试期间，Endgame Master 需要每天把当前测试进展同步给所有人，比如说总共有多少需要测试的项，哪些已经验证通过，哪些还没验证。
VS Code 的各个阶段
VS Code 的需求收集和版本计划
- VS Code 的需求收集和版本计划
需求来源
- 一部分是团队内部产生的
- 一部分是从社区收集的，比如 GitHub、Twitter、StackOverflow 的反馈。
VS Code 每半年或一年会对下一个阶段做一个Roadmap，规划下一个半年或一年的计划，并公布在 GitHub 的 WIKI 上，这样用户可以及时了解 VS Code 的发展，还可以根据 Roadmap 上的内容提出自己的意见。大的 RoadMap 确定后，就是基于大的 RoadMap 制定每个迭代具体的开发计划了。
版本迭代
- 当前迭代：当前正在开发中的 Milestone；
- On Deck：下一个迭代对应的 Milestone；
- Backlog：还没开始，表示未来要做的；
- Recovery：已经完成的迭代，但是可能要打一些补丁。
- VS Code 的设计和开发
VS Code 的开发流程也是用的GitHub Flow，要开发一个新功能或者修复一个 Bug，都创建一个新的分支，开发完成之后提交 PR。
- PR 合并之前，必须要有核心成员的代码审查通过，并且要确保所有的自动化测试通过。你也可以在 VSCode 的Pull requests中看到所有提交的 PR，去看看这些 PR 是怎么被 Review 的，每个 PR 的自动化测试的结果是什么样的。
- VS Code 对自动化测试代码也是非常重视，在实现功能代码的时候，还要加上自动化测试代码。VS Code 的CI（持续集成）用的是微软自己的 Azure DevOps，每一次提交代码到 GitHub，CI 都会运行单元测试和集成测试代码，对 Windows/Linux/macOS 三个操作系统分别运行测试。
- VS Code 的测试
前面提到了，迭代的最后一周是 End game，这一周就是专门用来测试的，并且有轮值的 Endgame Master 负责整个测试过程的组织。具体测试的时候，大家就是遵循 Endgame Master 制定好的测试计划，各自按照 Check List 逐一去检查验证，确保所有的新功能都通过了测试，标记为修复的 Bug 真的被修复了。对于验证通过的 Bug，在对应的 Issue 上打上 verified 的标签。在人工测试结束后，Endgame Master 就需要跑冒烟测试，确保这个迭代的改动不会导致严重的 Bug 发生。如果你的团队也没有专职测试，可以学习 VS Code 这样的做法：留出专门的测试阶段，事先制定出详细的测试计划，把所有要测试的项都通过测试跟踪工具跟踪起来，开发人员按照测试计划逐一测试。
- VS Code 的发布流程
- 创建 release 分支，比如说 release/1.10 ，后面的预发布版本和正式版本包括补丁版本都将从这个 release 分支发布。
- 如果在创建 release 分支后发现了新的 Bug，那么对 Bug 修复的代码，要同时合并到 master 和 release 分支。每一次对 Release 的代码有任何改动，都需要重新测试。
- 每次 Release 代码修改后，都会发布一个新的预发布版本，邀请大约两万的内部用户进行试用，然后看反馈，试用 24 小时后没有什么问题就可以准备发布正式版本。
- 发布正式版本之前，还要做的一件事，就是 Endgame master 要写 Release Notes，也就是你每次升级 VS Code 后看到的更新说明，详细说明这个版本新增了哪些功能，修复了哪些 Bug。
- 除此之外，VS Code 每天都会将最新的代码编译一个最新的版本供内部测试，这个版本跟我们使用的稳定版 Logo 颜色不一样，是绿色的 Logo。
VS Code 使用的工具
- VS Code 使用的工具VS Code 的源代码管理工具: GitHub，整个开发流程也完全是基于 GitHub 来进行的。它的任务跟踪系统是用的 GitHub 的 Issue 系统，用来收集需求、跟踪 Bug。通过标记不同的 Label 来区分Issue 的类型和状态，比如 bug 表示 Bug，feature-request 表示功能请求，debt 表示技术债务。通过 Issue 的 Milestone 来标注版本。
- VS Code 的持续集成工具:微软的Azure Pipelines。
- VS Code 的文档: GitHub 的 WIKI 系统，一部分是它网站的博客系统。WIKI 主要是日常项目开发、维护的操作说明，博客上更多的是一些技术分享。另外 VS Code 团队还自己开发了一些小工具，比如说帮助对 Issue 进行自动处理回复的 GitHub 机器人 VSCodeBot。通过这些工具的使用，基本上就可以满足像 VS Code 这样一个项目的日常运作.