Gitee Go：把托管流水线变成可审计的交付链
一次普通功能提交触发了 Gitee Go 流水线。测试通过，部署也显示成功，线上却运行着另一份代码。复盘发现测试阶段和发布阶段分别构建了一次，依赖解析结果不同；制品没有摘要，日志只记录了文件名；开发者既能改流水线，也能使用生产变量。平台没有宕机，交付链仍然失去了可证明性。
托管 CI/CD 的价值是少维护一套调度控制面，不是把架构责任交给网页。团队仍要回答：谁能改交付逻辑，哪个任务能读取 Secret，构建运行在哪里，制品是否不可变，部署主机如何隔离，配额耗尽怎样降级，离开平台时能带走什么。
先建立四层对象模型
Gitee Go 的使用入口在仓库或企业控制台。一次交付可以按四层理解：流水线承接触发与整体状态；阶段表达顺序边界；任务是被调度的执行单元；插件或命令完成检出、构建、测试、制品和部署动作。
阶段顺序解决“先测试还是先发布”，任务并行解决“哪些检查可同时执行”，但它们都不自动保证制品一致。可靠链路的核心不变量是：测试、审批和生产看到的是同一份带摘要的候选制品。
启用前先做一次数据与权限判断
准备一个无生产副作用的验证仓库、一名仓库管理员、一名普通开发者和一名只读成员。确认源码、依赖、测试数据、日志和制品是否允许进入托管执行环境；真实客户数据、生产数据库副本和长期生产密钥不能因为“只用于测试”就默认上传。
进入目标仓库后，找到流水线或 Gitee Go 入口。若入口不存在，依次检查账号与仓库归属、企业是否启用该能力、当前角色是否可见、手机号或组织策略是否满足平台要求。不要用另一仓库的页面推断当前仓库也有相同能力。
首次启用按下面的顺序操作：
在控制台创建最小流水线，暂不配置任何 Secret 和部署目标。若目标实例同时提供可视化编排与 YAML 编排，分别创建最小样例，记录保存后实际生成或修改的仓库文件；不要假定两种入口能无损互转。保存前审查触发条件、阶段、任务、插件和工作目录。
首次运行只打印允许展示的运行时版本并执行仓库内验证脚本。从构建历史核对源提交、触发人、阶段、任务、退出状态和日志。再增加候选制品，最后才接入部署主机和生产凭据。
平台页面、插件字段和 YAML 结构会随实例形态与版本变化。团队应把当前控制台生成且能被当前实例成功保存的配置当作 Schema 起点，再用一条成功运行和一条故意失败运行确认语义。禁止从 GitHub Actions 或 GitLab CI 搬入 runs-on、needs、secrets 等字段后靠试错猜测兼容性。
把可复现逻辑放回仓库
托管平台最容易形成的锁定，是把几十个命令散落在图形任务中。更稳妥的结构是：平台只编排，仓库脚本执行确定性动作。
ci/
verify.sh
package.sh
publish.sh
deploy.sh
rollback.sh
docs/
delivery-runbook.md创建 ci/verify.sh：
#!/usr/bin/env sh
set -eu
input=${1:-ci/input.txt}
test -f "$input"
grep -qx 'release-candidate' "$input"
printf 'VERIFY_OK input=%s\n' "$input"创建 ci/package.sh：
#!/usr/bin/env sh
set -eu
rm -rf dist
mkdir -p dist
cp ci/input.txt dist/app.txt
sha256sum dist/app.txt > dist/SHA256SUMS
cat dist/SHA256SUMS在流水线中建立“检查”和“构建”两个阶段，分别执行：
sh ci/verify.sh
sh ci/package.sh正向输入是：
mkdir -p ci
printf 'release-candidate\n' > ci/input.txt
sh ci/verify.sh
sh ci/package.sh预期日志含 VERIFY_OK，两个命令退出码均为 0，dist/SHA256SUMS 中的摘要与 sha256sum dist/app.txt 一致。把 dist/ 交给当前实例提供的制品或发布记录能力，并在制品元数据中记录源提交和本次运行编号。
反向实验把输入改成：
printf 'unsafe-change\n' > ci/input.txt
sh ci/verify.shgrep 应返回退出码 1，检查阶段失败，构建和发布阶段不应执行。若页面显示成功，检查任务是否用 || true、是否忽略脚本退出码，或图形任务是否调用了错误工作目录。这个反例同时证明平台确实消费了当前提交，而不是复用上一次输出。
配置任务时逐项验证字段影响
创建任务时不要一次填满所有选项。先固定运行镜像或工具链，再设置工作目录、命令、超时和输出；每增加一个字段就从运行详情确认它是否生效。
工具版本决定依赖解析结果。Node、JDK、Maven、Gradle 或 Go 版本应在仓库基线中声明，日志只输出版本号，不输出环境变量全集。工作目录错误通常表现为“脚本不存在”或锁文件找不到；网络代理错误通常表现为依赖下载超时、证书校验失败或访问内部仓库被拒绝。
超时不是性能优化。它用于终止失控任务并释放并发，但必须配合脚本的中断清理。部署脚本收到终止后，应停止继续批次、保留当前变更证据，并把目标状态标为待人工判断；不能捕获所有错误后仍返回零。
缓存只保存可再生成的依赖，不保存候选制品和 Secret。缓存键至少包含操作系统、架构、工具链和锁文件摘要。命中错误缓存的典型证据是同一提交在清空缓存后结果改变；处理方法是先隔离新键，而不是立即删除全公司缓存。
权限必须用目标实例取证
流水线权限通常与仓库角色紧密关联，但只读、开发者、管理员在不同实例中的最终动作边界可能不同，企业自定义角色和审批还会继续改变结果。上线前必须在目标仓库用真实测试账号取证。
建立如下权限实验，不使用生产流水线：
| 动作 | 只读成员 | 开发者 | 管理员 | 证据 |
|---|---|---|---|---|
| 查看运行与日志 | 实测 | 实测 | 实测 | 页面与审计记录 |
| 手工执行 | 实测 | 实测 | 实测 | 运行触发人 |
| 修改流水线 | 实测 | 实测 | 实测 | 仓库差异或审计事件 |
| 删除流水线 | 实测 | 实测 | 实测 | 删除确认与审计事件 |
| 下载制品 | 实测 | 实测 | 实测 | 下载结果与拒绝状态 |
| 使用部署变量 | 不直接读取值，只验证任务是否获授权 | 同左 | 同左 | 无副作用连接测试 |
判断标准不是页面上有没有按钮，而是动作成功或拒绝后是否留下主体、时间、对象和结果。若开发者可以同时修改流水线、读取生产凭据并执行发布，必须通过保护分支、独立审批、凭据隔离或外部发布系统拆开职责。
变量与 Secret 用无敏感值先探路
先创建普通变量 DELIVERY_ENV=lab，在受信任测试流水线中只输出该普通值，确认仓库、流水线、阶段和任务之间的作用域。不要预设同名参数在全局、流水线、阶段、任务和手工触发之间的优先级：为每层设置不同的非敏感值，分别运行并记录最终值，随后删除冲突项。再创建一项可随时撤销的测试凭据，任务只调用无副作用接口，不打印值本身。
下面四种触发来源要分别实测：仓库默认分支、普通分支、Pull Request、Fork。每次只判断任务是否获得授权，不通过 echo、Base64 或异常堆栈观察 Secret。日志掩码不是安全边界，恶意脚本仍可能拆分或外传值。
生产凭据至少拆成源码读取、制品上传、测试环境部署和生产部署四类身份。每项凭据记录 owner、用途、作用域、目标资源、到期时间和撤销入口。轮换时先加入新凭据并完成无副作用验证，再切换引用，最后撤销旧凭据；删除平台变量并不代表下游令牌已经失效。
制品要从“文件名”升级为“身份”
构建成功后保存候选制品、SHA256SUMS、源提交、运行编号、工具链版本和测试结果。发布任务只接收这组对象，不重新执行 package.sh。如果平台发布记录不能提供不可变版本、长期保留、签名或跨项目权限，就把 Maven、npm、OCI 等正式制品放进专业仓库，流水线只保存索引和证据。
发布前重新计算摘要：
sha256sum -c dist/SHA256SUMS成功时输出 dist/app.txt: OK 并返回 0。故意修改 dist/app.txt 后再运行，预期输出 FAILED 并返回非零；发布任务必须停止。这个反向实验能抓住下载损坏、错误覆盖和“同文件名不同内容”。
制品保留策略按用途分层：PR 临时产物可短期清理；候选版本保留到发布窗口结束；生产版本至少覆盖业务回滚窗口和审计要求。删除前先确认它不是当前或上一生产版本，不要用流水线页面的“禁止下载”代替归档与销毁策略。
部署 Agent 与主机组只承担受控发布
需要访问局域网或云主机时，在主机管理页面创建主机组，并把它只关联到授权仓库或项目。根据当前实例页面生成 Agent 或代理主机的安装步骤，在一台专用低权限主机执行；安装命令可能携带短期注册材料，不要复制到工单、聊天、Shell 历史或仓库，执行后还要检查进程参数和安装日志是否残留可复用值。
安装完成后依次验证：页面显示的 Agent 状态达到可用；代理主机能访问平台服务端；它能访问目标主机的受控端口；部署账号只能写指定目录和控制指定服务；无权限仓库不能选择该主机组。若页面要求访问 server-agent.gitee.com，还要在企业代理和防火墙中保留域名、方向和审计记录。
这类 Agent 首先是持续部署连接点，不能未经证据就当成通用自托管 CI Runner。若架构需要自托管构建，必须在目标实例确认它是否支持构建任务调度、工作区隔离、并发、缓存、镜像、升级和故障回收；缺少任一项时，仍按“云端构建、受控 Agent 部署”设计。
部署脚本接收不可变制品摘要和目标环境：
sh ci/deploy.sh --artifact-sha256 "$ARTIFACT_SHA256" --target staging脚本先校验摘要，再检查目标健康状态，部署到新目录，切换指针，最后做冒烟验证。失败时停止后续批次并保留旧目录。回滚调用 rollback.sh 恢复上一摘要，不从当前分支重新构建。
构建历史是排障入口，不是结果装饰
排障从运行编号开始，依次核对源提交、触发方式、阶段状态、任务退出码、开始结束时间、执行环境和制品摘要。截图可以辅助沟通，但长期证据应能按运行编号检索。
模板创建后立即失败
先在本地或等价容器运行仓库脚本，再检查工作目录、工具版本、锁文件和网络。模板只能提供起点，不能证明适配当前仓库。不断增加插件会掩盖第一处失败。
页面保存后行为与旧教程不同
比较图形视图和代码视图，审查平台实际提交的文件，再从运行详情确认触发与阶段。不要添加猜测字段兼容历史版本；若升级会自动改写配置，先在验证仓库完成迁移。
变量存在但任务拿不到
使用无敏感测试值逐层检查作用域、名称大小写、触发来源和任务位置。若默认分支成功而 PR 失败，这可能是保护策略，不应通过扩大生产变量作用域绕过。
制品无法下载或内容不一致
先检查当前角色、制品状态和保留策略，再核对运行编号与摘要。能下载同名文件但摘要不同，比“无法下载”更危险，应立即停止发布并调查覆盖策略。
Agent 显示异常或部署不通
按页面状态、Agent 日志、到平台服务端网络、到目标主机网络、部署账号权限和主机组关联逐层定位。不要只用 ping 判断，也不要把其他 CI 平台的“Runner 在线”术语当作当前页面证据。
托管构建耗时突然波动
记录排队时间与执行时间，区分平台并发、构建机规格、依赖网络和脚本自身变慢。配额与商业能力会变化，需要稳定容量时应以当前控制台、采购合同和压测基线制定预算，不把历史宣传值写进容量模型。
容量、成本与平台依赖
每月统计流水线次数、排队时间、执行分钟、失败重跑、缓存命中、制品增长和出网流量。执行分钟高不一定是业务增长，也可能是测试不稳定、依赖重复下载或失败后从头重跑。
容量评审至少模拟三种情况：日常提交峰值、版本发布峰值、平台部分能力不可用。关键修复流程应能在开发机或备用 CI 运行仓库脚本；生产回滚不能依赖重新获得云端构建配额。
采购或续费时，以目标实例页面和有效合同逐项确认并发、构建规格、分钟、存储、保留、支持、数据地域，以及是否存在满足合规要求的部署形态；公开产品页没有承诺的私有化能力、配额或服务等级一律不能写进架构前提。把迁移成本也纳入总成本：流水线逻辑越依赖专有插件，退出时越难复现。
升级、清理和退出
托管服务的变更窗口通常不由租户控制，因此团队要把“升级”改造成持续兼容性验证。定期在验证仓库保存当前有效配置、可视化与 YAML 入口的实际差异、代表性成功和失败运行、变量权限矩阵及制品摘要；发现页面、Schema、插件行为或合同能力变化后，先跑无 Secret 的正反实验，再验证测试凭据、制品与主机组，最后恢复生产发布。
清理验证环境时，先删除临时主机组关联和测试 Agent，再撤销测试令牌，删除临时变量与制品，最后删除验证流水线。保留必要的审计记录，但确认日志和制品中没有残留 Secret 或客户数据。
离开 Gitee Go 时，导出仓库内流水线配置和脚本，迁移制品与摘要，重建变量和权限矩阵，验证备用平台能跑通同一正反实验。切换完成后禁用旧触发、撤销服务身份、解除主机组关联；确认没有生产回滚依赖后再按保留策略删除历史对象。
团队治理基线
每条生产流水线要有业务 owner 与平台 owner。业务 owner 维护测试、构建和回滚语义；平台 owner 维护权限、变量、配额、主机组和审计；安全负责人审批不可信输入、敏感数据和生产凭据边界。
每季度用测试账号重做权限矩阵，用 Fork 或普通分支确认生产 Secret 不可用，抽取一个生产版本从摘要恢复，并检查上一版本仍可回滚。每次平台页面、合同或插件发生变化，都先更新实例验收记录，再调整团队基线。
上线检查
平台只负责编排，验证、构建、发布和回滚逻辑都能从仓库脚本复现。成功与无害失败实验都验证过实际退出状态、阶段阻断和日志证据。图形视图与代码视图的变更都经过仓库评审。
只读、开发者和管理员的运行、修改、删除与下载权限已在目标实例取证。PR、Fork、受保护分支和人工发布使用不同的变量与凭据边界。候选制品带源提交、运行编号和摘要，生产只提升同一份制品。
部署 Agent 使用专用账号、受控网络和最小主机组关联。未经现场证据，没有把部署 Agent 当成通用自托管 CI Runner。队列、执行分钟、缓存、制品存储、重跑和出网成本持续统计。
配额、并发、规格、保留和支持以当前实例与合同为容量依据。平台升级、错误发布、凭据泄漏和退出迁移都有演练过的停止与恢复路径。