Firefox开发版是Mozilla Firefox的一个分支，它是一个实验性的浏览器，用于测试新功能和改进。它是Mozilla Firefox的最新版本，但不保证稳定性或可靠性。
Firefox开发版具有许多新功能，包括对WebRTC的支持、对WebGL 2.0的支持、对ES6的支持、对CSS Grid Layout的支持以及其他一些新特性。此外，Firefox开发版还包含了一些实验性功能，如“快速切换”、“快速启动”和“快速关闭”等。
// 启用 WebGL 2.0 webgl2.enabled = true; // 启用 CSS Grid Layout layout.css.grid-template-masonry-value.enabled = true; // 启用 ES6 javascript.options.ion.content = true;
原文链接：http://www.aosabook.org/en/cmake.html
作者：Chris AtLee, Lukas Blakk, John O"Duinn, Armen Zambrano Gasparian
最近，Mozilla发布工程组在Firefox的发布自动化方面取得了非常多的进步。我们已经减少了在签字和发送通知时对人工参与的要求，并且自动化了许多其它的小的手工步骤，因为流程中每个手工步骤都可能犯错。尽管仍不算完美，我们始终在尽最大努力自动化发布过程，最终目标是真正的一键式发布；最小化人工干预将会消除我们在之前那种半人工半自动化的发布过程中所经历过的重复劳动和许多令人头疼的事情。在本章，我们将带着你走入并领略构成完整的Firefox快速发布系统的脚本和架构的世界（到Firefox 10为止）。
你将会看到一个可发布的Mercurial变更集是如何成为候选发布，进而成为公开发布的，此时就对全世界每日高达4亿5千多万的用户完全开放了。我们将会从构建和代码签名开始，接下来是定制的合作伙伴和本地化重打包，QA过程，以及如何为每个支持的版本、平台和本地化生成更新。每一个步骤都必须正确的完成，一个发布才可以被推送到Mozilla社区的镜像网络上供用户下载。
我们将会看到一些旨在改善此流程的决定；例如，健康检查脚本，帮助消除了许多人工错误导致的问题；自动签名脚本；移动发布集成到桌面发布流程；补丁程序，用来创建更新；以及应用更新服务（AUS - Application Update Service），将更新发送给使用着各种不同版本的用户。
本章描述了如何产生Firefox发布构建的机制，大部分篇幅都在讲解一次构建开始后发布流程的各个关键步骤。但是，在发布工程开始产生发布构建之前，还需要做足够的复杂的跨团队沟通。因此，我们就从这里开始吧。
图2.2：完整的发布时间线，以chemspill为例
谁来决定进入构建
在发布开始之前，一个人被指定负责协调整个发布过程。他/她需要参加类选会议、理解所有项目背景、公平的仲裁bug严重性上的争议、批准最新的变更、做出艰难的放弃决定等等。最后，在发布日，这个角色在现场负责与各个团队的所有沟通：开发、QA、发布工程、网站开发、公共关系、市场等等。
这个角色在不同的公司有不同的称呼：发布经理、发布工程师、Program Manager、项目经理、产品经理、产品沙皇、发布舵手等等。本章将使用“发布协调员”这一称谓，因为我们觉得这个词最清楚的表达了该角色在我们的流程里起的作用。重点在于这个角色及其代表的最终权威能够被每个人所清楚的理解，无论其背景或之前在其它地方的工作经历。在发布日，每个人都知道自己应该遵守和信任这个角色所做出的协调决定。
发布协调员也是发布工程之外唯一一个有权在重大问题出现后发出“停止构建”邮件的人。任何疑似重大问题报告也会被发送到发布协调员，由他/她来评估及做出go/no-go的决定，并及时的将此决定周知到每个人。在发布日，我们所有人必须遵守和信任这个角色所作出的协调决定。
如何发出“进入构建”信号？
早先通过IRC或者电话口头的通知带来了很多误解，时常给进行中的发布造成问题。因此，我们现在要求“go to build”信号通过电子邮件发送到一个包含了与发布过程相关的所有团队的每个人的邮件列表。邮件标题包含“go to build”加上产品名及版本号，例如：go to build Firefox 6.0.1。
类似的，如果出现了问题，发布协调员会发送一个新的“all stop”邮件给同样的邮件列表。我们发现另外一种做法——回复该发布的最新的邮件——是不行的，因为一些客户端的邮件会话功能会造成一些人注意不到藏的很深的“all stop”邮件。
在“Go to Build”邮件里有些什么？
a) 类似“使用最新代码”这样的指令是绝对不行的；曾经有一个发布，在“go to build”邮件发出之后而构建开始之前，一个好心的开发未经批准提交了一个变更到一个错误的分支，导致发布将此变更包括在构建中。幸好这个错误在交付之前被发现了，但是，我们因而完全终止、全部重新构建，并推迟了发布。
b) 在象CVS这样的基于时间的版本控制系统里，要十分明确的使用准确的时间；精确到秒，并指定时区。曾经有一个发布，在Firefox还使用CVS的时候，发布协调员指定了一个构建的截至时间但是未说明时区。当发布工程注意到缺失时区信息时，发布协调员睡着了。发布工程正确的猜想应该是本地时间（加利福尼亚）。然而，在一次深夜的发布中，我们将PST看作了PDT，结果丢了最后一个关键的bug修复。这个错误在交付之前被QA发现了，但是我们不得不停止并使用新的截至时间重新构建。
2.对于特定发布的清晰的紧迫感。听起来显而易见，但在处理一些重要的特例时非常重要，简单总结如下：
a) 一些发布是例行的，可以在正常工作时间完成。这些都是预先安排的发布，也会按时完成，不存在紧急性。当然，所有发布的构建都需要及时的创建，只是不需要发布工程师熬夜赶工去完成。我们会事先做好安排，人们只需要在正常上班时间工作就可保证每件事情都按时完成。这将保持大家的体力，以便更好的应对那些意料之外的紧急工作。
b) 一些发布属于chemspill这样紧急性的，需要争分夺秒。典型的例子包括修复公开的安全漏洞，或者修复影响大量用户的崩溃性问题。Chemspills需要被尽快创建，而不是按预先的安排。
c) 一些发布在例行和chemspill之间转换。例如，当一个例行发布的安全修复意外的泄漏了，就变成了一个chemspill发布。当一个业务需求如给即将到来的一次会议公告准备的“特供预览”发布，由于商务原因被延迟时，就从chemspill发布变为例行发布。
d) 一些发布的性质存在争议，因为对相同的修复存在不同角度的理解。
正是发布协调员这个角色，负责平衡所有这些事实和观点，达成决定，并将有关紧迫性的决定清楚一致的周知到所有团队。一旦有新的信息，发布协调员会重新评估和周知。一些团队认为一个发布是chemspill而另外的团队认为是例行的，这种情形对跨团队的合作是非常有害的。
最后，这些邮件对于度量一次发布中的时间分配非常有用。尽管它们的准确度不会超过挂钟的时间粒度，但对于我们判断下一步应该把工作集中在哪里以加快速度来说已经是非常有用的了。正如古老的格言所说，先有度量，才能改进。
在Firefox的beta周期里，我们也在做mozilla-beta库的周发布。每个这样的beta发布都要经过我们通常的完整的发布自动化，与常规的最终发布几乎一模一样。为了最小化意外，发布自动化流程或底层架构在开始最终发布构建之前不能有任何未经测试的变化。
图2.4: 对每一个语言进行Firefox重打包
现在，我们将整个repacks分成六个作业，放在六台不同的机器上并行执行。这种方法将时间减少到了原来的六分之一。这也使得我们可以在个别repack失败时重做一部分作业，而不是全部。我们可以将repacks分成更多、更小的并行的作业，但发现这将会占用太多的机器，进而影响到在持续集成系统上运行的由开发启动的无关作业。
移动发布（Andoid）流程稍有不同，因为我们仅产生两个安装包：一个英语版的，一个多语言版的将一打语言一块放进安装包里而不是每个独立的构建放一个。多语言版本的大小是一个问题，尤其是对移动设备的慢速下载而言。可能的一个改进是其它语言按需请求并从addons.mozilla.org取得。
在图2.4里，可以看到语言信息依赖三个不同的源：shipped_locales，l10_changesets 和 l10n-changesets_mobile-release.json。（计划合并成一个统一的JSON文件）这些文件包含不同本地化的信息以及某些平台例外。特别的，对于某个给定的本地化，我们需要知道对于给定的发布使用库的哪个修订，以及是否它可以用于所有支持的平台（例如，Mac上的日语来自于一个不同的库）。Desktop发布有两个这种文件，而移动发布有一个（此JSON文件包含平台列表和变更集）。
谁来决定发布哪种语言呢？首先，本地化负责人自己提名特定的变更集，然后由Mozilla的本地化小组评审，显示在一个web仪表盘里，其中列出了每种语言需要的变更集。发布协调员也会在发出“go to build”邮件前进行评审。发布的时候就可以获取变更集列表，加入到重打包中。
除了本地化重打包以为，我们还进行合作伙伴重打包。这是为希望定制其客户体验的各个合作伙伴而当定制的构建。主要的变化是定制的书签、主页和搜索引擎，但是很多其它的事情也可以被改变。这些定制的构建是为最新的Firefox发布生成的，不适用于beta版。
为了让用户肯定他们下载的Firefox是真实的来自Mozilla且未经篡改的版本，我们使用了几种不同类型的数字签名。
第一种签名用于Windows版本，我们使用了Microsoft Authenticode（signcode）签名键去签署.exe和.dll文件。Windows可以使用这些签名来验证应用来自可信赖源。我们还用Authenticode键对Firefox的安装程序进行的签名。
接下来我们使用GPG为所有平台上的所有版本生成一系列MD5和SHA1校验和，为校验和文件及所有构建和安装程序生成分割的GPG签名。这些签名供镜像网站及其它社区成员进行下载验证。
出于安全目的，我们有一个专门的通过防火墙和VPN与外部链接隔离的签名机器。Keyphrases, password和keystores通过安全通道在发布工程师间传送，经常是亲自取送，以最小化泄漏的风险。
