发布流程

标准路径

1. 功能、递增的 version 和 CHANGELOG 经普通 source MR 合入受保护 master。版本变更的 MR merge 是发布决定。
2. 唯一的版本变更 master CI 作业核对递增版本与 exact master head，创建受保护的 autodev-v<version> tag。普通 master commit 不启动 CI；Plane Automation 业务服务只观察 tag，不创建它。
3. Exact tag pipeline 运行完整发布前检查、六组件 build/reuse、Harbor seal、TEST render 与 TEST GitOps MR 自动合并。
4. Argo CD 协调 plane-test。TEST observer 核对运行健康，专用 TEST runner 完成业务验收。任一失败都停止后续阶段。
5. 同一 tag pipeline 验证 TEST desired state、运行观察与封闭的 plane.test-acceptance/v1 artifact 后，创建 PROD GitOps MR；该 MR 的 branch CI 通过后自动合并 exact head。
6. Argo CD 协调 plane-production，最终 PROD observer 核对 exact desired state、Argo、migration/smoke、workloads、pods、image digests 与 endpoint。观察成功才完成发布。

仓库原生控制入口

autoai/autodev-plane 的 deployments/gitlab/release/control.py 仅提供只读 plan 和 status。创建 tag、环境推进与运行观察均由 GitLab CI、GitOps 和 Argo CD 的 owning surfaces 执行。DSH 和 TeamCity 不是 Plane release operator、observer 或 fallback。

失败处理

CI success 不等于 runtime health；TEST smoke 不等于业务验收。version/tag/commit/pipeline/digest/MR head 漂移、CI 失败、TEST 验收失败或 Argo 健康无法证明时，停止该 release。修复走 owning source 的普通 MR，并使用新的 immutable version/tag；不移动旧 tag，不手工重建或绕过 TEST。

权威链接

构建与部署指南 · 运维恢复