67 lines
2.9 KiB
Markdown
67 lines
2.9 KiB
Markdown
# 流水线、发布与最终验收
|
||
|
||
## 目录
|
||
|
||
1. 环境证据边界
|
||
2. R11发布完成
|
||
3. CI02回调POC
|
||
4. CI03证据分离
|
||
5. R12最终验收
|
||
6. L01–L02历史规则
|
||
7. 连锁触发验证
|
||
|
||
## 1. 环境证据边界
|
||
|
||
分别记录以下事件，未经批准不得互相替代：
|
||
|
||
- test环境部署成功。
|
||
- 生产环境流水线发布成功。
|
||
- 云效关联发布变更达到完成状态。
|
||
- 产品/业务验收完成。
|
||
|
||
流水线成功不等于测试用例通过，test成功也不默认等于生产发布完成。
|
||
|
||
## 2. R11发布完成
|
||
|
||
优先使用“关联发布变更达到项目真实完成状态”作为R11证据。规则要求当前状态=`测试完成`，目标环境和发布证据满足组织口径。
|
||
|
||
如果组织明确把test部署定义为“完成发布”，必须记录该口径的批准证据；否则test回调只记录测试部署成功，不推进发布完成。
|
||
|
||
## 3. CI02回调POC
|
||
|
||
1. 复制现有test流水线并使用明显POC名称。
|
||
2. 保留原test与prod流水线不变。
|
||
3. 只在副本Docker部署成功路径末尾添加回调。
|
||
4. 普通变量传工作项ID、环境、流水线执行ID。
|
||
5. 密钥变量保存认证材料，不写入仓库、命令输出或文档。
|
||
6. 请求携带时间戳、签名和执行ID幂等键。
|
||
7. 服务端校验需求当前状态，只允许预期流转执行一次。
|
||
8. 测试成功、重复回调、错误签名、超时、部署失败和安全重试。
|
||
9. POC通过后走推广评审，不直接修改prod。
|
||
|
||
## 4. CI03证据分离
|
||
|
||
CI03要求项目配置分别保存test、prod、发布变更和验收证据。任何桥接都必须记录实现方式、启用状态、负责人、证据和人工回退。
|
||
|
||
回调失败保留失败日志并可安全重试，不得伪造成功。同一执行ID重试不得多次推进需求。
|
||
|
||
## 5. R12最终验收
|
||
|
||
发布成功不等于业务验收。默认由产品/业务负责人确认后人工进入`已完成`或`已关闭`。只有可靠、可审计的验收任务才允许条件化自动关闭。
|
||
|
||
## 6. L01–L02历史规则
|
||
|
||
- `L01`：`发布完成 + 全部关联任务完成/关闭 → 项目终态`。默认停用或收紧为独立验收任务，避免早期阶段任务误满足。
|
||
- `L02`：监听`测试完成 → 发布完成`状态路径并立即进入项目终态。默认停用，防止发布完成成为瞬时状态。
|
||
|
||
逐项目记录两条规则是否存在、是否启用、真实条件、顺序和证据；不存在也要有盘点证据。
|
||
|
||
## 7. 连锁触发验证
|
||
|
||
- 不按规则名称推断行为，逐条读取触发、条件、动作、顺序和执行账号。
|
||
- 每个目标状态都检查后继规则和重复规则。
|
||
- R11后至少观察两个时点：刚进入发布完成时，以及等待5–30秒后。
|
||
- 未经验收自动进入终态时，记录实际后继规则并判定`误触发`。
|
||
- 跨两级以上流转必须有独立负向测试，不能只验证最终状态。
|
||
|