构建与部署指南

一步启动

通过普通 MR 同时更新 autoai/autodev-plane 的 release/package.json 与 CHANGELOG.md，并将 MR 合入受保护的 master。版本号必须递增且尚未被 autodev-v<version> 使用。合并版本变更就是发布决定；无需手动创建 tag、下载验收文件、播放手动 job 或合并环境 MR。

普通 master 变更不启动 CI。只有 release/package.json 发生变更时，master CI 才核对实际版本递增与 exact master commit，并创建该 commit 的受保护版本 tag。既有 tag 不会移动或复用。

自动流水线

1. Tag 流水线先完成 Python contracts、Web types、API schema 与业务用例，再构建或精确复用六个组件，封存不可变 Harbor digests。
2. 流水线生成并自动合并 TEST GitOps MR；Argo CD 协调 plane-test。
3. 独立 TEST observer 核对 Argo revision、sync/health、migration、workloads、exact digests 与 endpoint；专用 TEST runner 执行业务验收并输出绑定 tag/commit/pipeline/bundle 的 plane.test-acceptance/v1 artifact。
4. 两项 TEST 作业通过后，流水线核对 exact artifacts，生成 PROD GitOps MR，等待该 MR 的 CI 通过并合并 exact head。PROD 复用 TEST 的同一 Harbor bundle 和六个镜像 digest。
5. Argo CD 协调 plane-production；最后的 PROD observer 核对应用、hook、工作负载、镜像和 endpoint。该作业成功才算发布完成。

查看进度与失败恢复

在 GitLab 查找 exact autodev-v<version> tag pipeline，记录 version、tag、commit、pipeline id、Harbor bundle 和六个 digest。仓库内 deployments/gitlab/release/control.py 只提供 plan 与 status --release-version <version> --commit <sha> --pipeline-id <id> 只读查询；不得根据 latest tag、Plane 业务状态或旧流水线推断。

任一检查、TEST 验收、GitOps MR CI、PROD observer 失败时，发布停止。修复 owning source，通过新的普通 MR 和新版本重新发布；不得移动旧 tag、手改 desired state、直接改集群或跳过 TEST。

完成标准

同一 version/tag/commit/pipeline 必须绑定通过的检查、Harbor bundle/六镜像 digests、TEST 与 PROD 两个已合并 GitOps MR、TEST 验收及两份运行观察。GitLab 作业成功不能单独代替 Argo 和 endpoint 健康证据。

权威链接

发布流程 · 运维与恢复