跳到主要内容

发布故障排除与恢复

本网页提供了在 WooCommerce 发布过程中可能出现问题的故障排除和恢复指南。它涵盖了常见场景、推荐操作以及最佳实践，以帮助确保发布过程顺利进行，并高效地解决任何问题。

场景 / 常见问题解答​

构建发布时，工作流程失败​

  1. 打开 GitHub 中工作流程运行的详情（在 Actions 选项卡下），以查看确切的失败位置和原因。 通常，工作流程会显示清晰的错误信息。
  2. 仔细阅读错误信息。 有时，问题可能只是由于缺少工作流程配置或跳过某个步骤。
  3. 如果您不确定错误意味着什么或如何继续， 请随时在发布 Slack 频道寻求帮助。 获得第二意见总比猜测要好。

⚠️ 在您了解失败的原因之前，请勿重新运行任何工作流程。 重新运行而不修复根本问题可能会使情况更加复杂。

与发布相关的 PR 上，CI 测试失败​

在发布过程中，您可能会遇到与发布相关的 PR 上的 CI 测试失败。 这些失败有时是由于测试修复已合并到主分支，但在创建发布分支之前未回溯到该分支。

  1. 识别原因： 检查失败的测试是否在主分支上通过。 如果通过，则可能需要将修复回溯到发布分支。
  2. 回溯测试修复： 如果可能，回溯来自主分支的相关测试修复到发布分支，然后重新运行 CI 工作流程。
  3. 处理复杂情况： 如果由于依赖关系或其他原因无法回溯，请记录您发现的内容，并在发布 Slack 频道寻求帮助。 "Heart of Gold - Flux" 团队可以协助解决阻止发布工作的 CI 问题。

最终发布的 ZIP 文件出现问题，我可以重新开始吗？​

如果在下载并解压生成的制品后，发现出现问题（例如，缺少文件、变更日志不正确或版本不匹配），这通常意味着：

  • 某个必需的工作流程未运行或失败（例如，跳过了变更日志步骤）。
  • 来自工作流程的自动生成的 PR 在构建 ZIP 文件之前未合并到发布分支。

在尝试重新构建版本之前：

  1. 删除任何与错误版本相关的 GitHub 草稿版本或标签：
    • 转到 代码 > 版本 并删除草稿版本。
    • 在 代码 > 标签 中，删除与错误版本的标签。如果跳过此步骤，最终版本可能会指向历史记录中的错误提交。
  2. 检查 release/X.Y 分支的状态（可以在 GitHub UI 中或在本地拉取最新更改后进行检查）。
  3. 找出哪个步骤失败。例如，如果插件头版本正确但缺少变更日志，则只需重新运行变更日志步骤。
  4. 审查任何 自动生成的 PR：如果存在未合并且不再需要的打开的 PR，请关闭它们并删除其分支。

一旦您知道哪个步骤失败， 仅重新运行该步骤，具体方法请参阅 构建和发布指南。 确保以正确的顺序运行跳过的流程，并在继续之前仔细检查所有配置（版本号、发布类型等）。

在内部检查/监控期间检测到严重错误​

对于 RC 和稳定版本，在公开发布之前，必须将版本部署到我们的测试环境并进行错误监控。 如果在监控期间检测到严重错误，请执行以下步骤：

  1. 请求回滚 测试环境中的部署。
  2. 立即暂停发布过程，并且不要继续执行跟踪问题中剩余的任何步骤。
  3. 更新跟踪问题，说明发布已阻止，并包含有关错误的详细信息。
  4. 不要发布 任何已创建的 GitHub 草稿版本，但也不要删除 它们。 稍后将与通过验证的版本一起发布它们。
  5. 与相关的工程团队 协调，以开发修复程序。
  6. 如果需要调整或公开沟通发布计划，请联系开发者支持团队 (有关延迟的更多信息，请参阅下文)。

错误修复合并到发布分支后，如何操作？​

  1. 创建新的跟踪问题，用于新的版本（例如，如果错误是在 -rc.1 版本中检测到的，则为 -rc.2；如果是在监控 x.y.1 版本时检测到的，则为 x.y.2），通过运行 Release: Create Tracking Issue 工作流。不要重复使用现有的跟踪问题。
  2. 按照正常的发布流程，处理新的版本。
  3. 发布所有受影响版本的草稿版本。即使之前的版本没有公开可用，也必须将其发布，并且每个版本都将有自己的变更日志部分。

在 WordPress.org 上标记为稳定的版本中出现了一个严重错误。​

如果发现严重的回归或错误（例如，结账失败或无法恢复的数据丢失）：

  1. 立即通知相关的工程团队。
  2. 准备进行一个 Point Release。
  3. 暂时将 WordPress.org 上的稳定标签回退到之前的已知良好版本：
    • 确定正确的先前版本，并记录其确切版本号。
    • 使用 Release: Update stable tag 工作流，确保选中 Revert 选项，以允许降级。
    • 立即合并任何自动生成的 PR。

发布需要延迟。我们应该怎么办？​

  1. 创建一个内部 Slack 频道，以便与工程团队以及 Dev Advocacy 团队进行沟通。这还为团队提供了一个机会，可以分享任何额外的上下文，并验证或质疑时间表变更。
  2. 安排 Dev Advocacy 团队公开宣布延迟。
  3. 如果对包含修复的补丁版本有明确的预计发布时间 (ETA)，请 更新发布日历，添加新的日期。

请记住，不要计划补丁版本的发布 过于接近周末。

发布已延迟。我们是否可以在周二之后仍然发布？​

一般来说，应避免在周二之后发布，尤其是在接近周末的时候。

即使补丁已经准备好并且似乎解决了问题，也很难确定是否没有其他隐藏的问题，并且在周末晚些时候发布可能会导致大多数团队成员无法监控或响应问题。

一般来说，如果犹豫不决，最好推迟一周的发布，以确保万无一失。