背景 Link to heading

以前的系统发布模式为平均每3个月一次系统发布——开发周期2个月,测试周期1个月。这虽然保证了每次系统发布的状态都比较稳定,但是仍然避免不了在大量用户在不同场景下产生而发现新 BUG 的局面,而且因为这种发布模式缺少快速更新的机制,导致很多在内部已经得到修复的问题无法及时推送到外网,用户在这段时间内只能忍受一些 BUG 的干扰。所以,我们在 15.6 和 15.7 的时候引入了”发布后一个月“的概念,在这个时间段内,开发主要做问题修复工作,修复的内容可以快速推送到外网,而不用经过繁杂的测试,期望快速解决用户在使用新版本中遇到的问题,这就是深度滚动更新的原型。

15.8开发的过程中,我们又思考了一下这个过程,刚巧我们决定了要尝试”开放和透明“、拥抱社区,所以觉得目前这种把”大教堂“和”集市“两种开发模式揉在一起的方式不是特别明朗,对系统发布者和开发者都是一种负担,所以”从善如流“——从 15.9 开始,deepin 系统的发布开始遵循滚动更新的模式。

滚动更新流程 Link to heading

深度的滚动更新,需要参与系统发布的产品、开发和测试共同合作,所以制定了一套简单的工作流程作为大家协作的基础,从粗到细主要分为了以下几个范围:

1. 系统版本 Link to heading

系统版本的概念跟以前的 15.7、15.8 等没有不同,都会提前指定这 2 - 3 个月的一个工作计划,在阶段性工作完成之后,会有新版本的 ISO 发布。与之前不同的是,新功能不是等系统发布的时候一次性放出,而是在每周开发内容完成、测试通过以后就会放出;另外一个不同是,系统发布不再以完成所有开发内容为前提,而是在系统版本计划的时间点达到以后即发布,未完成的内容放入下个版本工作内容中。

工具使用:

  • 系统版本规划的内容会展示在官网的“版本规划”中进行展示;
  • 需求文档会邮件通知所有参与系统发布的同事。

2. 里程碑 Link to heading

由于前面所说的新版本不会要求计划内容都完成才发布,所以为了防止工作计划与实际工作产出相差过大,所以将每次系统版本发布做了阶段划分,也就是里程碑。举个例子来说,15.9 开发的阶段会划分为 15.8.1、15.8.2、 15.8.3、 15.8.4 等。

在每次里程碑开始之前,产品需要提前细化里程碑内的需求,在里程碑开始之前还未明确的需求,会被放入下个里程碑中。同样,在这个阶段,测试会根据产品需求编写测试用例。需求和测试用例都会经过一次评审。每个里程碑到达预定时间点之后,未完成的工作内容会按照优先级放入下个里程碑或者延后处理、放到其他里程碑中。

工具使用:

  • 里程碑使用 github issues 中的 Milestone 工具来进行管理;
  • 细化的需求文档以及需求变更会邮件通知所有参与系统发布的同事。

3. 工作周 Link to heading

每个里程碑由两个工作周组成。在每个工作周内,开发需要完成计划中的开发内容和上个工作周测试问题的修复工作,在每周结束的时候,开发对稳定的项目打 tag,并提交到 crp 平台进行打包、提供 changelog 供产品和测试在下个工作周进行验收。同样,在每个工作周内,产品和测试需要完成对上周开发内容的验收工作,保证在周三前完成功能验收、功能测试和 BUG 修复,周四时发布更新。

工具使用:

  • 系统各个组件包版本控制、changlog 使用 crp 进行管理;
  • 每周更新内容在 internal-discussion 中建相应里程碑发布任务的 issue 进行说明;
  • 社区官网提供每次更新的更新注记。

目标 Link to heading

目前对滚动更新的期望主要有以下几点:

  1. 提升用户使用体验和满意度;
  2. 提升社区活跃度;
  3. 增加系统发布工作的灵活度;
  4. 发挥产品、开发和测试团队每个人的主观能动性;
  5. 最终整体上提高系统的稳定性和质量。

注:本文档将在 developer-center wiki 持续更新。