http://www.infoq.com/cn/news/2014/07/release-process-mozilla-firefox 从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或者电话来发出构建新版本的命令,但他们遇到了问题,后来改成了发送电子邮件给发布流程中涉及的所有人,邮件的标题含有文本“开始构建+产品名称+版本号”。这封电子邮件包含了即将构建和发布的这个版本的源代码的详细信息,如果代码仓库是基于时间戳的,信息中包括代码对应的时间和时区。 整个发布过程包含以下步骤: 在这套发布流程的演进过程中,Mozilla也吸取了一些教训: - 要成功发布一个版本,在流程中有发言权的相关各方都要考虑到,不管是技术的还是非技术的,这很重要。
- 使每个人都意识到这个发布流程,以及时间都花哪儿了。一开始,Mozilla内部人员认为一个新版本的发布仅仅是发布工程师的事,但实际上很多其他人都和这个流程有关,他们都对某些环节负有责任。
- 发布流程中出现的大多数问题都是这些因素有关,“团队间沟通不畅;缺乏明确的牵头人;以及发布安全修复版本带来的压力、疲劳和焦虑”。“使用简单明了的方式传递信息,消除人为的误解”,这种方法解决了这个问题。
- 团队稳定性也是个问题:太多的工程师干了一段时间后就离开了发布团队,其他顶替他们的人,也只是晚点走而已。这导致了“缺乏准确且与时俱进的文档,这意味着对发布流程的大多数技术理解仅靠民间口口相传来维护,随便一个人离职后,这种口头经验就遗失了”。在Mozilla开始重视发布版本这件事情后,情况就改观了,工程师们开始觉得“Mozilla有改善现状的计划,团队终于能在一定程度上掌控自己的命运了”。
- 以小步快跑的方式改进发布流程,每个新版本做得比以前好一点。随着自动化流程的改进,团队也能腾出时间来进一步改进流程。
这几位作者提到,发布流程已经改进到相当不错的程度,Mozill发布最近8个安全修复版本只用了两天时间,这几个版本用于定位Firefox用到的一个第三方库中存在的安全漏洞,之前的测试并没有覆盖到这个第三方库。
|