注意

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

开发工作流程

本页面解释了开发者预期遵循的工作流程，以实现 Ceph 发布周期中的一部分目标。它不涉及技术细节，而是旨在提供高层级的概览。每一章都是关于一个特定的目标，例如Merging bug fixes or features或Publishing point releases and backporting.

所有工作流程的一个关键方面是，它们都不会阻塞另一个。例如，一个错误修复可以在下一个点发布正在发布时回滚并合并到稳定分支。为了使这个特定的示例起作用，应该创建一个分支以避免任何干扰。在实践中，对于 Ceph 来说不是必要的，因为：

  • 参与的人很少

  • 回滚的频率不是太高

  • 审核者知道发布正在进行，不太可能合并任何可能导致问题的内容

这种临时方法意味着工作流程会定期更改以适应。例如，quality engineers没有参与发布dumpling点发布的流程。回滚到firefly的提交数量使得开发者任务，编写代码或修复错误，同时运行和验证完整的集成测试套件变得不切实际。插入quality engineers使得有人可以通过分析测试结果参与工作流程。

当工作流程强制执行会带来不合理的开销时，它们不会被强制执行。例如，如果点发布的发布说明在检查所有集成测试之前没有编写，它们可以提交到稳定分支，并将结果发送用于发布，而无需再次运行集成测试。

发布周期

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）。见理解发布周期 for more information.

合并错误修复或功能

开发分支是master，所有开发者遵循的工作流程可以总结如下：

  • 开发者准备一系列提交

  • 开发者通过拉取请求提交一系列提交

  • 分配一个审核者给拉取请求

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

  • 集成测试运行成功后，测试者合并拉取请求

The developer是一系列提交的作者。 Thereviewer负责定期向开发者提供反馈，开发者被邀请在一周后如果没有发生任何事情时@审核者。审核者满意拉取请求后，（他/她）将其传递给reviewer is satisfied with the pull request, (s)he passes it to the tester一起使用。该tester负责在拉取请求上运行 teuthology 集成测试。如果一个月内没有任何动静，则邀请reviewer@审核者tester.

解决错误报告并实现功能

所有错误报告和功能请求都在问题追踪器中，工作流程可以总结如下：

  • 报告者创建具有优先级的问题Normal

  • 开发者可以立即选择问题

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

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

每个team负责一个项目，由领导.

The developer分配给问题的开发者负责该问题。一个打开的问题的状态可以是：

  • New: 不清楚是否需要处理该问题。

  • Verified: 错误可以重现或多次出现

  • In Progress: 开发者本周正在处理它

  • Pending Backport: 修复需要回滚到稳定发布字段中列出的稳定发布

对于每个Pending Backport问题，在Backport追踪器中至少存在一个问题以记录从主分支挑选必要提交到目标稳定分支所做的工作。参见回滚者手册 for more information.

运行和解释 teuthology 集成测试

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

The quality engineer是开发者或 QE 团队成员。每个项目至少有一个集成测试套件：

以及许多其他套件，例如

准备新的发布

在一个专门的分支上准备发布，不同于master分支。

  • 对于稳定发布，它是与发布代码名称匹配的分支（dumpling、firefly 等）

  • 对于开发发布，它是next分支

所有开发者稳定发布候选人的工作流程与正常开发工作流程相同，但有以下区别：

  • 拉取请求必须指向稳定分支或下一个而不是主分支

  • 审核者拒绝不是错误修复的拉取请求

  • The Backport与 teuthology 测试失败匹配且具有优先级的问题Urgent在发布之前必须修复

切割新的稳定发布

当满足以下条件时，可以切割新的稳定发布：

  • all Backport优先级Urgent的问题已修复

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

发布新的稳定发布意味着在升级过程中存在回归或发现新错误的风险，无论测试多么小心。切割发布的决定必须考虑这一点：发布一个仅修复几个小错误的稳定发布可能不明智。例如，如果只有一个提交被回滚到非 LTS 的稳定发布，最好等到有更多提交时再发布。

当要退役稳定发布时，建议升级到下一个 LTS 发布可能比提议一个新的点发布来修复问题更安全。例如，4b7d9c: v0.67.11 发布与回填相关的错误已在dumpling v0.67.11 release has bugs related to backfilling which have been fixed in fireflyv0.80.x 中修复。一个修复这些回填错误的回滚已在草拟点发布dumplingv0.67.12 中测试，但它们足够大，以至于引入回归风险。由于dumpling将退役，受此错误影响的用户可以升级到firefly来修复它。除非用户表明自己并要求dumplingv0.67.12，这个草拟发布可能永远不会发布。

  • The Ceph lead决定必须发布新的稳定发布

  • The release master从所有领导者获得批准

  • The release master编写并提交发布说明

  • The release master通知quality engineer分支已准备好进行测试

  • The quality engineer运行额外的集成测试

  • 如果未设置quality engineer发现需要修复的新错误，发布将回到准备阶段，它本来就不准备好了Urgent Backport, the release goes back to being prepared, it was not ready after all

  • The quality engineer通知publisher分支已准备好发布

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

每个角色的负责人是：

  • Sage Weil 是Ceph lead

  • Sage Weil 是release master主要稳定发布的负责人（firefly0.80，hammer0.94 等）

  • Loic Dachary 是release master稳定点发布的负责人（firefly0.80.10，hammer0.94.1 等）

  • Yuri Weinstein 是quality engineer

  • Alfredo Deza 是publisher

切割新的开发发布

开发发布的发布工作流程与准备新发布和切割相同，但有以下区别：

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

  • The quality engineer不需要运行额外测试，release master直接通知publisher发布已准备好发布。

发布点发布和回滚

点发布的发布工作流程与准备新发布和切割相同，但有以下区别：

  • The backport每个问题字段包含稳定发布的代码名称

  • 对于每个稳定发布，在问题追踪器中恰好有一个问题用于回滚问题Backport tracker for each stable release to which the issue is backported

  • 所有提交都使用git cherry-pick -x来引用原始提交

请参阅回滚者手册 for more information.

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.