注意

本文档适用于 Ceph 的开发版本。

开发工作流

此页面解释了开发人员为实现 Ceph 发布周期中的目标而应遵循的工作流。它不涉及技术细节，旨在提供一个高层次的视图。每个章节都围绕一个特定的目标，例如 合并错误修复或功能 或 发布小版本和向后移植。

所有工作流的一个关键方面是它们互不阻塞。例如，在发布下一个小版本的同时，可以将错误修复向后移植并合并到稳定分支中。要使这个特定的示例奏效，应该创建一个分支以避免任何干扰。在实践中，Ceph 没有必要这样做，因为

  • 涉及的人员很少

  • 向后移植的频率不是很高

  • 知道正在发布版本的审阅者不太可能合并任何可能导致问题的代码

这种临时方法意味着工作流会定期更改以适应情况。例如，在发布 dumpling 小版本的工作流中，并未涉及 质量工程师。向后移植到 firefly 的提交数量使得负责编写代码或修复错误的开发人员难以同时运行和验证整套集成测试。引入 质量工程师 使得某人可以通过分析测试结果来参与工作流。

当工作流带来的开销没有意义时，它们不会被强制执行。例如，如果小版本的发布说明是在检查所有集成测试之前编写的，则可以将它们提交到稳定分支，并将结果发送以供发布，而无需再进行一次集成测试运行。

发布周期

Ceph              hammer                             infernalis
Developer          CDS                                  CDS
Summit              |                                    |
                    |                                    |
development         |                                    |
release             |  v0.88  v0.89  v0.90   ...         |  v9.0.0
               --v--^----^--v---^------^--v-     ---v----^----^---  2015
                 |          |             |         |
stable         giant        |             |      hammer
release        v0.87        |             |      v0.94
                            |             |
point                    firefly       dumpling
release                  v0.80.8       v0.67.12

每年四次，在 Ceph 开发者峰会 期间在线讨论开发路线图。新的稳定版本（hammer、infernalis、jewel...）以相同的频率发布。每隔一个版本（firefly、hammer、jewel...）是一个 长期稳定版（LTS）。有关更多信息，请参阅 了解发布周期。

合并错误修复或功能

开发分支是 master，所有开发人员遵循的工作流可概括如下

  • 开发人员准备一系列提交

  • 开发人员通过拉取请求提交这一系列提交

  • 审阅者被分配到该拉取请求

  • 当审阅者认为拉取请求看起来不错时，由测试人员将其合并到集成测试分支中

  • 在集成测试成功运行后，由测试人员合并拉取请求

开发人员 是一系列提交的作者。审阅者 负责定期向开发人员提供反馈，如果一周后没有进展，开发人员被邀请提醒审阅者。在 审阅者 对拉取请求满意后，他/她将其传递给 测试人员。测试人员 负责在拉取请求上运行 teuthology 集成测试。如果一个月内没有进展，审阅者 被邀请提醒 测试人员。

解决错误报告和实现功能

所有错误报告和功能请求都在 问题跟踪器 中，工作流可概括如下

  • 报告者创建问题，优先级为 Normal

  • 开发人员可以立即选择该问题

  • 在每两周一次的错误清理会议上，团队会检查所有新问题并分配优先级

  • 优先级别较高的错误首先处理

每个 团队 负责一个项目，由 领导者 管理。

被分配到某个问题的 开发人员 负责该问题。开放问题的状态可以是

  • New（新建）：不确定是否需要处理。

  • Verified（已验证）：错误可以重现或多次出现

  • In Progress（进行中）：开发人员本周正在处理

  • Pending Backport（待向后移植）：修复需要向后移植到 backport 字段中列出的稳定版本

对于每个 Pending Backport 问题，在 Backport 跟踪器中至少存在一个问题，用于记录从 master 分支挑选必要提交到目标稳定分支的工作。有关更多信息，请参阅 向后移植手册。

运行和解释 teuthology 集成测试

Sepia 社区测试实验室 定期 运行 teuthology 集成测试，结果发布在 pulpito 和 ceph-qa 邮件列表上。

  • 作业失败由 质量工程师和开发人员分析

  • 如果原因是环境问题（例如网络连接），则在 sepia lab project 中创建问题

  • 如果错误已知，则将失败作业的 pulpito URL 添加到问题中

  • 如果错误是新的，则创建一个问题

质量工程师 既可以是开发人员，也可以是 QE 团队成员。每个项目至少有一个集成测试套件

以及许多其他套件，例如

准备新发布

发布准备在一个专用分支中进行，不同于 master 分支。

  • 对于稳定版本，它是与版本代号匹配的分支（dumpling, firefly, etc.）

  • 对于开发版本，它是 next 分支

所有开发人员为稳定发布候选版本而应遵循的工作流与正常开发工作流相同，但有以下区别

  • 拉取请求必须针对稳定分支或 next，而不是 master

  • 审阅者拒绝非错误修复的拉取请求

  • 匹配 teuthology 测试失败并设置优先级为 Urgent 的 Backport 问题必须在发布前修复

发布新的稳定版本

在以下情况下可以发布新的稳定版本

  • 所有优先级为 Urgent 的 Backport 问题已修复

  • 集成和升级测试运行成功

发布新的稳定版本意味着存在回归的风险或在升级过程中发现新错误，无论测试多么仔细。发布版本的决定必须考虑到这一点：发布仅修复少量小错误的稳定版本可能不明智。例如，如果只向非 LTS 稳定版本向后移植了一个提交，最好等到有更多提交时再发布。

当一个稳定版本即将退役时，建议升级到下一个 LTS 版本可能更安全，而不是为修复问题而提议一个新的小版本。例如，dumpling v0.67.11 版本存在与回填相关的错误，这些错误已在 firefly v0.80.x 中修复。修复这些回填错误的向后移植已在草稿小版本 dumpling v0.67.12 中进行测试，但它们足够大，可能引入回归风险。由于 dumpling 即将退役，遇到此错误的用户可以升级到 firefly 来修复它。除非用户表明自己并要求 dumpling v0.67.12，否则此草稿版本可能永远不会发布。

  • Ceph 领导者 决定必须发布新的稳定版本

  • 发布主管 获得所有领导者的批准

  • 发布主管 编写并提交发布说明

  • 发布主管 通知 质量工程师 分支已准备好进行测试

  • 质量工程师 运行额外的集成测试

  • 如果 质量工程师 发现需要 Urgent Backport 的新错误，则发布返回到准备阶段，因为它毕竟还没有准备好

  • 质量工程师 通知 发布者 分支已准备好发布

  • 发布者 创建软件包并设置发布标签

每个角色的负责人是

  • Sage Weil 是 Ceph 领导者

  • Sage Weil 是主要稳定版本（firefly 0.80, hammer 0.94 etc.）的 发布主管

  • Loic Dachary 是稳定小版本（firefly 0.80.10, hammer 0.94.1 etc.）的 发布主管

  • Yuri Weinstein 是 质量工程师

  • Alfredo Deza 是 发布者

发布新的开发版本

开发版本的发布工作流与准备新版本和发布新版本相同，但有以下区别

  • 发布后，next 分支会重置为 master 的尖端

  • 不需要 质量工程师 运行额外的测试，发布主管 直接通知 发布者 版本已准备好发布。

发布小版本和向后移植

小版本的发布工作流与准备新版本和发布新版本相同，但有以下区别

  • 每个问题的 backport 字段包含稳定版本的代号

  • 在 Backport 跟踪器中，每个向后移植该问题的稳定版本恰好有一个问题

  • 所有提交都通过 git cherry-pick -x 挑选，以引用原始提交

有关更多信息，请参阅 向后移植手册。

由 Ceph 基金会为您呈现

Ceph 文档是由非营利性 Ceph 基金会 资助和托管的社区资源。如果您希望支持这项工作和我们的其他努力，请考虑 立即加入。