class="topic_img" alt=""/>
从 2004 年开始，Mozilla 发布了很少几个版本的 Firefox，到 2010 年 7 月，版本号达到了 4.0。但是从 2011 年开始，Mozilla 学习 Google，改变了他们的发布周期，现在的版本号是 30。一直以来，发布工程师团队不断改进着做一个新版本浏览器的流程。工程师四人小组——Chris AtLee、Lukas Blakk、John O'Duinn、Armen Zambrano Gasparian，在 Dr. Dobb's杂志上发表了一篇文章，描述了发布流程的细节，在这里我们将会把这个流程的精华展示给大家。
Mozilla 考虑到他们的浏览器可能会有的安全漏洞，设计了一套发布流程，可以快速地制作一个“安全修复”版本，这个版本会迅速地推送给用户，以便及时修复已知的漏洞。整个流程会尽可能地自动化，减少“人力介入”，并改进“健壮性和开发周期”。安全修复版本和常规版本都会用到这个流程。每个版本发布后，Mozilla 会做一个事后分析，看看是否有可以改进的问题。在下一个版本发布前，发现的问题会很快被修复。
发布流程由一名发布协调人员来发起，这个人需要“参加分类会议，理解这个版本中各个修改的来龙去脉，公正地仲裁 bug 严重性等级方面的争议，批准合入最新的修改，以及做出取消发布的艰难决定。”
Mozilla 以前通过 IRC 或者电话来发出构建新版本的命令，但他们遇到了问题，后来改成了发送电子邮件给发布流程中涉及的所有人，邮件的标题含有文本“开始构建+产品名称+版本号”。这封电子邮件包含了即将构建和发布的这个版本的源代码的详细信息，如果代码仓库是基于时间戳的，信息中包括代码对应的时间和时区。
整个发布过程包含以下步骤：
发布协调人员发出“开始构建”（Go-to-Build）的电子邮件
开始打标签——像 FIREFOX_30_0_RELEASE 这样的标签被打到大约 85 个代码库中——包括产品、本地化字符串、自动发布用到的代码和工具——这些都是创建一个特定版本的浏览器所需要的。整个过程持续大约 20 分钟，因为代码库实在太多，Mozilla 想并行处理打标签过程，每个库单独一个进程，这样可以把时间缩短到 5 分钟。
- 构建开始——许多构建版本协同运行起来，每个发布平台一个，加上刚刚打完标签的所有源代码。编译结果被上传到ftp.mozilla.org 上。这个步骤还包括了本地化“重新打包”：en-US 区域的版本被解开，然后把所有 en-US 字符串替换成对应区域的字符串，再重新打包。
- 签名——二进制文件要签名。对于 Windows 来说，所有的 EXE 和 DLL 都要签名，包括安装程序本身。然后再生成一系列的 MD5 和 SHA1 校验和，这样镜像服务器可以校验它们下载的文件是否正确。签名在一台与外界隔绝的专用服务器上进行。密码、密钥和密钥库只会在发布工程师们私人之间的安全通道内传播。
- 测试——对于安全修复版本来说，测试人员会对导致升级版本的安全漏洞进行手动测试。如果问题还在，必须先修复，整个构建流程要重来。
- 制作升级包——升级包被制作出来，准备就绪后，浏览器的更新程序会去下载它们。有大量的升级包要做，每个平台、每种语言、基于每个旧版本都要有一个。
- QA 测试——一旦签过名的版本准备就绪，社区成员、外包人员和 Mozilla 员工会对它进行手动测试，他们也会测升级包。与此同时，自动化的功能测试流程也会开始。如果一切正常，QA 团队最终会签发这些版本和升级包。
- 更新镜像——升级包会被推送到世界各地的镜像服务器上。整个流程完成后，发布协调人员会发送一封电子邮件，宣布新版本准备就绪，这封邮件带有“上线”（Go Live）字样，然后发布工程师们更新网站和 FTP 服务器，确保它们指向最新的版本。
在这套发布流程的演进过程中，Mozilla 也吸取了一些教训：
- 要成功发布一个版本，在流程中有发言权的相关各方都要考虑到，不管是技术的还是非技术的，这很重要。
- 使每个人都意识到这个发布流程，以及时间都花哪儿了。一开始，Mozilla 内部人员认为一个新版本的发布仅仅是发布工程师的事，但实际上很多其他人都和这个流程有关，他们都对某些环节负有责任。
- 发布流程中出现的大多数问题都是这些因素有关，“团队间沟通不畅；缺乏明确的牵头人；以及发布安全修复版本带来的压力、疲劳和焦虑”。“使用简单明了的方式传递信息，消除人为的误解”，这种方法解决了这个问题。
- 团队稳定性也是个问题：太多的工程师干了一段时间后就离开了发布团队，其他顶替他们的人，也只是晚点走而已。这导致了“缺乏准确且与时俱进的文档，这意味着对发布流程的大多数技术理解仅靠民间口口相传来维护，随便一个人离职后，这种口头经验就遗失了”。在 Mozilla 开始重视发布版本这件事情后，情况就改观了，工程师们开始觉得“Mozilla 有改善现状的计划，团队终于能在一定程度上掌控自己的命运了”。
- 以小步快跑的方式改进发布流程，每个新版本做得比以前好一点。随着自动化流程的改进，团队也能腾出时间来进一步改进流程。
这几位作者提到，发布流程已经改进到相当不错的程度，Mozill 发布最近 8 个安全修复版本只用了两天时间，这几个版本用于定位 Firefox 用到的一个第三方库中存在的安全漏洞，之前的测试并没有覆盖到这个第三方库。
相关文章