DevOps 工具链：Jenkins 三级流水线与制品治理

「治大国若烹小鲜。」发版如同火候——火猛了烧焦，翻动太频鱼就散。成熟的工具链必须减少翻动：把语义定死、把时间稳住，让「发版」从事件变成日常。本篇复盘本仓 44 个 job 的三级流水线与制品治理。

一、界定：流水线不是仪式，是语义的承重墙

三级结构 ci → release → deploy 不是为了好看，而是把三种不同性质的承诺分开承重：ci 承诺「代码可检」（lint / 测试 / 构建），release 承诺「制品可复现」（版本源、tag、镜像指纹、漏洞阈值），deploy 承诺「服务可就绪」（容器重建 + 就绪检查）。张冠李戴（比如在 deploy 里补测试）时，承诺就会互相吞吃。

栈	版本字段	git tag
backend	backend/pom.xml revision（flatten 插件管理）	<app>-v<version>
frontend	frontend/apps/<app>/package.json version	同口径

二、为什么必须：三类翻车史

这条流水线的每条纪律下都躺着一次翻车：镜像 tag 被占用——相同版本号指向不同 commit 时若直接覆盖，历史环境会拉到面目全非的镜像，所以约定 tag 冲突宁可再 bump 版本、绝不覆盖；增量编译假 SUCCESS——某次资源修改后构建绿而启动失败，关键变更一律全量 clean package 验证；Liquibase 语法坑——dollar-quote 与非法属性都在部署的就绪闸门处被拦下，而不是在生产里安静腐烂。三条翻车指向同一句话：工具链必须把「惯例」变成「可判定事实」。

三、机理：幂等、指纹与阈值

release 的制品治理四件套：版本直接从 pom / package.json 读（参数化触发只补变量，禁手工传错）；git tag 幂等——已存在且指向同一 commit 则跳过继续推镜像，指向不同 commit 则失败（重跑 job 必须 safe）；镜像三 tag（version / sha-<commit7> / latest）加五条 OCI label（title / version / revision / source / ref.name）；Trivy 扫描 CRITICAL 阻断（--ignore-unfixed 跳过无可修漏洞，漏洞库经 Nexus 缓存）。deploy 按 IMAGE_TAG 重建容器并验收就绪：后端 9005 起来而健康检查未达就绪即 FAILURE——就绪闸门是流水线的最后一道良心。

jenkins pipeline

四、思辨：确定性与自由的对价

「绝不覆盖 tag」的严格常让人不快：版本号没赶上还得再 bump。但换算一下这笔账：滥用 tag 的自由，兑换的是某天三小时的环境混乱追查；再 bump 一次付出的是几秒钟的决定。确定性是有价的，而且它的价格几乎总是便宜得惊人——就像错过的那班火车晚一分钟关门，是为了让所有人坐上同一班车。

五、回到现实：每次发版三查