分阶段更新

向扩展的用户库子集推出稳定的版本更新，以便在将更新推送给每个人之前检测到严重的回归，并且该过程停止。其目的是为了让回归影响到我们用户群中较小的一部分。

当前状态

一旦更新发布到updates，更新就会分阶段进行，以便扩展的Ubuntu用户子集可以逐渐使用更新。此过程允许我们自动监控回归，并在发现任何回归时停止更新过程。有关流程的完整详细信息可以在博客帖子作者：Brian Murray。

Phased-Update-Percentage最初设置为10%，然后运行一个作业（每6小时一次），检查是否存在回归，如果没有回归，则阶段更新百分比将增加10%。因此，更新将在54小时或大约2天后完全分阶段进行。如果检测到回归，Phased-Update-Precentage将设置为0%，从而导致受支持的包管理器不安装更新。

分阶段更新的进度在报告它由执行阶段化的同一作业更新。

截至Focal（20.04），Update Manager是唯一支持分阶段更新的包管理器(参考). 任何其他更新机制都会安装所有更新，而不考虑分阶段更新百分比。

发行说明

StableRelease更新将不再同时出现在所有计算机的更新管理器中。相反，将随机选择一个子集的机器来首先接收更新。只有当第一组用户没有遇到严重的退化时，才会向所有人提供更新。在任何用户收到更新之前，Ubuntu开发人员仍然需要完成一个测试过程。

理论基础

一次性将任何广泛使用的软件程序的全新版本提供给我们的整个用户群是不必要的，充满了风险。

相反，让我们采用分阶段更新策略，将更新后的软件提供给不断扩展的随机用户。随着我们对软件更新的信心的增长，这个用户群将不断增长，这是由来自崩溃数据库和其他潜在来源的实时信息提供的。

该过程将与增加包装测试的工作同步进行-提议的以便我们对正在推出的更新更有信心。这个过程将增加拉动在大量用户遇到它之前进行更新。

用户故事

作为Ubuntu用户
我想在稳定版本更新中遇到回归的频率较低
以便我可以完成我的工作

作为Ubuntu开发人员
我想在每个人安装更新之前获得有关回归的反馈
以便我可以减少受影响的用户数量

作为Ubuntu预发布测试程序
我想立即安装所有更新
以便我能尽快看到破损

更新管理器

update-manager将仅当计算机处于当前状态时才处理可用的更新测试装置进行更新。

如果出现以下情况，则测试集中有一台计算机分阶段更新百分比✕ 2128≥md5(机器id+程序包名称+程序包版本).

(2128是可由md5型功能。）

此算法只需要包记录和机器id即可执行，速度相当快，因此不应显著降低计算可用更新列表的时间。

它是确定性的，因此对于特定的包和版本，在特定的阈值下，它的响应总是相同的。但它确实因包和版本而异，所以同一组用户并不总是找到回归的用户。

未解决的问题

  • 算法正确吗？
  • 我们想把这个新字段称为什么？
  • 如果包有另一个可用版本，并且算法对最新版本回答“否”，那么更新管理器应该怎么做？例如安全更新和更新的软件包更新。如果它不安装-updates版本，是否应该安装-security？可能。
  • 如果更新管理器每周弹出一次，是否会使分阶段更新变得毫无用处？
    • 假设默认值为一周，并且在一周中的哪一天（也就是说）有一个相当统一的分布，我们将发现安装了更新的实际人数百分比明显滞后于设置的数字。多少取决于人们安装更新的速度。如果每个人都在弹出窗口出现时立即安装，则更新将比理想曲线长大约一周才能完全传播，但大多数人将在更新在服务器端达到100%时安装更新。
    • 我们无法确切知道当前的百分比是多少，只能根据更新的阶段进行猜测。
    • 暂停更新时，应将阶段降低到0，以防止其他人安装，然后再重新升级，或跳到以前的值。
    • 考虑到该阶段不控制安装了更新的机器的百分比，并且非安全更新的“每周开放”默认设置提供了某种阶段化，此方案提供的主要功能是暂停更新而不从更新中删除它。这样做值得吗？
    • 将分阶段更新与update-manager中的一个选项相结合，使其仍然只显示非安全更新（结合根据是否显示特定机器的更新来计算该更新的更改），这对于平衡我们在推送更新时的控制，以及用户不希望每天都被更新提示打扰是有意义的。
  • 考虑到它是基于机器的，有多台机器的人会在不同的时间看到更新。这太令人困惑了吗？是否有办法关闭它（选择参加测试）？

档案文件

在服务器端，新分阶段更新百分比当我们想要分阶段更新时，需要填充字段。

Launchpad会将其插入包记录中。因此，它需要知道要插入什么值。它应该存储在Launchpad中的什么位置？

将向Launchpad添加一个API来设置该值，它将由ubuntu-sru（ubuntu-archive？）控制。

  • 我认为这应该类似于组件/节/优先级覆盖：也就是说，它应该是二进制包发布历史记录可以通过添加另一个可选参数来轻松设置二进制包发布历史记录.changeOverride。这将产生为包创建新发布的效果，因此不经常更改值（可能每天一次左右）是有益的；但为了让LP存档发布者生成新的Packages节，无论如何都需要一个新的发布，所以这是正确的。二进制包发布历史记录.changeOverride仅限于ubuntu-archive--cjwatson公司

然后将运行一个脚本来设置这些值。当一个包被推送到-updates中时，脚本将开始随着时间的推移增加百分比，并使用一些定义明确的包龄函数，可能还有紧迫性。

将覆盖该老化，允许ubuntu-sru暂停特定包的脚本，以便在出现可疑回归时使用。一旦决定了要做什么，包就可以在更新中被取代，在这种情况下，新版本的过程将重新开始，或者继续推出。

选择退出

默认情况下，Ubuntu的预发布版本应选择不进行分阶段更新。

参与者控制台的“更新”面板应该让测试人员选择退出发布后的分阶段更新，或者选择加入发布前的分阶段升级（以测试分阶段机制本身）。

未解决的问题

  • 信息应存储在Launchpad中的何处？
  • 应该允许谁更改值？
  • 对于特定的包，应该如何暂停该过程？
  • 卷展曲线应该是什么样子？

进一步发展

  • 可以将错误跟踪器中的自动链接添加到卷展栏脚本，以便在新版本崩溃时暂停传播。

用你正在更改或指定的每件事的标题替换该标题。

检查清单：

  1. 你看过相关软件包的错误报告了吗？（是的，这可能需要一两个小时。但您可以通过精心设计的更改修复多个错误。）
  2. 如果涉及任何用户界面，是否对其进行了全面描述？包括任何线框或模型。
  3. 你有没有新的用户界面，或新的可见文本，由设计师审查？（或者如果你是一名设计师，你是否接受过同行评审？）
  4. 是否可以进行更改？（例如，您是否为任何纯图形元素指定了可访问的标签？）
  5. 用户将如何学习新的做事方式？描述所需的任何帮助页面，以及对Ubuntu网站或安装程序幻灯片的任何更改。
  6. 是否需要迁移数据或设置？

  7. 如何测试该功能？请将条目添加到http://testcases.qa.ubuntu.com/Coverage/NewFeatures网站用于跟踪测试覆盖率。

未解决的问题

另请参阅

类别规范

阶段更新（上次编辑时间：2023-06-09 14:57:43内托西奥)