深度滚动更新工作流程

Hualet Wang edited this page Dec 19, 2018 · 1 revision

背景

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

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

滚动更新流程

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

1. 系统版本

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

工具使用:

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

2. 里程碑

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

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

工具使用:

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

3. 工作周

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

工具使用:

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

目标

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

  1. 提升用户使用体验和满意度;
  2. 提升社区活跃度;
  3. 增加系统发布工作的灵活度;
  4. 发挥产品、开发和测试团队每个人的主观能动性;
  5. 最终整体上提高系统的稳定性和质量。
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.