|
Deepin 系统终于切换为滚动更新了，滚动更新好，其实可以理解为，就是小步快跑。相对来说，以前的更新模式虽说会稳定些，但太满后于同行了，所以差距只会越来越大。以下介绍深度滚动更新工作流程及其目标。
背景 以前的系统发布模式为平均每3个月一次系统发布——开发周期2个月，测试周期1个月。这虽然保证了每次系统发布的状态都比较稳定，但是仍然避免不了在大量用户在不同场景下产生而发现新 BUG 的局面，而且因为这种发布模式缺少快速更新的机制，导致很多在内部已经得到修复的问题无法及时推送到外网，用户在这段时间内只能忍受一些 BUG 的干扰。所以，我们在 Deepin 15.6 和 Deepin 15.7 的时候引入了”发布后一个月“的概念，在这个时间段内，开发主要做问题修复工作，修复的内容可以快速推送到外网，而不用经过繁杂的测试，期望快速解决用户在使用新版本中遇到的问题，这就是深度滚动更新的原型。 Deepin 15.8开发的过程中，我们又思考了一下这个过程，刚巧我们决定了要尝试”开放和透明“、拥抱社区，所以觉得目前这种把”大教堂“和”集市“两种开发模式揉在一起的方式不是特别明朗，对系统发布者和开发者都是一种负担，所以”从善如流“——从 Deepin 15.9 开始，Deepin 系统的发布开始遵循滚动更新的模式。
滚动更新流程 深度的滚动更新，需要参与系统发布的产品、开发和测试共同合作，所以制定了一套简单的工作流程作为大家协作的基础，从粗到细主要分为了以下几个范围： 1、系统版本 系统版本的概念跟以前的 Deepin 15.7、Deepin 15.8 等没有不同，都会提前指定这 2 – 3 个月的一个工作计划，在阶段性工作完成之后，会有新版本的 ISO 发布。与之前不同的是，新功能不是等系统发布的时候一次性放出，而是在每周开发内容完成、测试通过以后就会放出；另外一个不同是，系统发布不再以完成所有开发内容为前提，而是在系统版本计划的时间点达到以后即发布，未完成的内容放入下个版本工作内容中。 工具使用： 1]、系统版本规划的内容会展示在官网的“版本规划”中进行展示； 2]、需求文档会邮件通知所有参与系统发布的同事。 2、里程碑 由于前面所说的新版本不会要求计划内容都完成才发布，所以为了防止工作计划与实际工作产出相差过大，所以将每次系统版本发布做了阶段划分，也就是里程碑。举个例子来说，Deepin 15.9 开发的阶段会划分为 15.8.1、15.8.2、 15.8.3、 15.8.4 等。 在每次里程碑开始之前，产品需要提前细化里程碑内的需求，在里程碑开始之前还未明确的需求，会被放入下个里程碑中。同样，在这个阶段，测试会根据产品需求编写测试用例。需求和测试用例都会经过一次评审。每个里程碑到达预定时间点之后，未完成的工作内容会按照优先级放入下个里程碑或者延后处理、放到其他里程碑中。 工具使用： 1]、里程碑使用 github issues 中的 Milestone 工具来进行管理； 2]、细化的需求文档以及需求变更会邮件通知所有参与系统发布的同事。 3、工作周 每个里程碑由两个工作周组成。在每个工作周内，开发需要完成计划中的开发内容和上个工作周测试问题的修复工作，在每周结束的时候，开发对稳定的项目打 tag，并提交到 crp 平台进行打包、提供 changelog 供产品和测试在下个工作周进行验收。同样，在每个工作周内，产品和测试需要完成对上周开发内容的验收工作，保证在周三前完成功能验收、功能测试和 BUG 修复，周四时发布更新。 工具使用： 1]、系统各个组件包版本控制、changlog 使用 crp 进行管理； 2]、每周更新内容在 internal-discussion 中建相应里程碑发布任务的 issue 进行说明； 3]、社区官网提供每次更新的更新注记。
深度滚动更新目标 目前对滚动更新的期望主要有以下几点： 1、提升用户使用体验和满意度； 2、提升社区活跃度； 3、增加系统发布工作的灵活度； 4、发挥产品、开发和测试团队每个人的主观能动性； 5、最终整体上提高系统的稳定性和质量。
结语 以上就是深度滚动更新的介绍，如果 Deepin 有一个稳定版，有一个开发版，开发版滚动更新，稳定版定期把开发版验证为有效可靠易用的功能加入，可能更好。
相关主题 |
