> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 验证一次发布

> 让每次发布在应用性能和用户体验中可见，在灰度期间对比新旧版本，并快速决定保留还是回滚。

大多数事件都始于一次变更。在数据中留下标记的发布，几分钟内就能与之前的版本对比；没人记录的发布，往往要猜上一个小时才能被发现。记录每一次发布，在灰度期间对比，并提前约定什么情况下回滚。

## 让每次发布都可见

| 步骤 | 做法 | 带来的能力 |
| - | - | - |
| 为每个 Span 标注版本 | 在每个服务的 OpenTelemetry 资源中设置 `service.version`。 | 即使 CI 没有上报，也能在[发布时间线](https://docs.molesignal.com/zh-Hans/apm/deployments.md#发布时间线)中看到版本和每个版本的对比结论。 |
| 从 CI 上报发布 | 用默认接入 Token 调用 `POST /api/v1/apm/deployments`，带上服务、版本、环境、提交和 CI 运行。参见[从 CI 上报发布](https://docs.molesignal.com/zh-Hans/apm/deployments.md#从-ci-上报发布)。 | 在版本旁显示提交、作者和 CI 运行，并记录失败或回滚的发布。 |
| 上报配置与功能开关 | 同一个端点，把 `kind` 设为 `configuration` 或 `feature_flag`。 | 非发布类的变更也会出现在应用性能发现的附近。 |
| 为前端标注版本 | 用户体验 SDK 的 `version`，以及在同一个 CI 任务中上传的 Source Map 或 Symbols。参见 [RUM Source Maps 与 Symbols](https://docs.molesignal.com/zh-Hans/rum/source-maps.md)。 | 可读的堆栈，以及知道自己在哪个版本回归的用户体验 issue。 |

所有地方使用同一个版本字符串：镜像标签、`service.version`、发布上报和用户体验版本。

## 发布前了解基线

灰度开始前，先记下服务当前的表现：主要端点的错误率和 P95、[SLO](https://docs.molesignal.com/zh-Hans/apm#服务等级目标) 的燃烧率，以及未解决的用户体验 issue。对关键路径的[拨测](https://docs.molesignal.com/zh-Hans/synthetics.md)执行一次 **立即运行**，以免把发布前就存在的失败误认为是发布引起的。

把回滚条件写下来，例如：版本在错误率上被判为 **变差**、某个关键拨测连续失败两次，或快速燃烧率告警触发。

## 灰度期间对比

* 两个版本同时运行时，[部署](https://docs.molesignal.com/zh-Hans/apm/deployments.md#金丝雀)页面的金丝雀卡片会把它们并排对比：各自承接的请求比例、错误和延迟，以及新版本的对比结论。
* 每个版本都会得到与前一个版本对比的结论：**变差**、**变好**、**无明显变化** 或 **请求不足**。对比需要足够的请求，默认 1,000 个；金丝雀要保持足够长的时间才能达到。
* 点击结论打开 **对比两个版本**，查看变慢的端点和增多的错误。
* 在用户体验中按新版本筛选探索页和错误 issue，并留意被标为 **回归** 的 issue：之前已解决、又在更新版本中出现的问题。

## 让自动化盯住发布

由 CI 任务启动的 Mole Agent [自动化](https://docs.molesignal.com/zh-Hans/automations.md#从-ci/cd-启动)可以先看一遍：发布步骤调用它的触发接口并附上变更说明，Mole Agent 按自动化的说明执行，例如对比新旧版本，然后在对话中汇报。是否回滚仍由人来决定。

## 做出决定并记录

满足回滚条件时就回滚，不必等到完全确定。从 CI 上报回滚，把 `status` 设为 `rolled_back`，这样时间线会显示它，之后的对比也会使用正确的基线。

保留下来的发布，要在接下来的一天里查看 SLO：内存泄漏、队列逐渐堆积这类缓慢的退化，往往几个小时后才会显现。

## 验收标准

* 每个服务都发送 `service.version`，每次生产发布都带着提交出现在发布时间线中。
* 前端发布上传了与所上报版本一致的 Source Map 或 Symbols。
* 灰度开始前已写下回滚条件。
* 每次发布都得到了对比结论，或金丝雀运行得足够长、达到了所需的请求数。

## 相关指南

* [部署](https://docs.molesignal.com/zh-Hans/apm/deployments.md)
* [RUM 错误与 issue](https://docs.molesignal.com/zh-Hans/rum/errors.md)
* [自动化](https://docs.molesignal.com/zh-Hans/automations.md)
* [守护关键用户旅程](https://docs.molesignal.com/zh-Hans/best-practices/user-journeys.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.