一次制品覆盖事故的复盘：CodeArts 流水线并行构建，为什么两条 deploy 都成功却只剩一个包

一、事故现场

一个代码仓里放 5 个微服务，Maven 多模块。CodeArts Pipeline 用并行 stage：每个微服务一个 job，各自跑 mvn deploy，目标都是同一个 release 仓。某天开始，下游服务偶发启动失败，报找不到依赖类。回头看流水线，全绿。

二、五个怀疑，四个被排除

1）版本号写错——排除，pom 里 version 是写死的。

2）groupId 冲突——排除，两个 model-core 的 groupId 不同。

3）制品仓库不支持同 artifactId 多 groupId——排除，用 API 逐个查，两个坐标都在，只是其中一个 size 明显不对。

4）并行写冲突——成立。

5）checksum 没校验——放大器。

三、根因：repository URL 少写了一段

settings.xml 里 deploy 的目标地址写成了 https://xxx/artgalaxy/repository/maven-releases/model-core/ 。带上 artifactId 之后，Maven 认为仓库根目录已经是 model-core，就不会再拼 groupId 路径。两个模块真正落地时指向同一个目录，后写的把先写的覆盖掉。

更难受的是：上传是覆盖写，服务端不校验 checksum，客户端只看到 200，于是日志里两条都是 BUILD SUCCESS。

四、三条修法

1）改 URL：只写到仓库根目录，让 Maven 自己拼 groupId / artifactId / version。改动最小，但要确认老坐标不被现有消费者依赖。

2）一服务一仓：每个微服务独立 repository，权限上还能做“只有本服务流水线可写”。改造量主要在 settings.xml 和权限配置。

3）deploy 串行收口：编译与单测保持并行，deploy 放到最后一个串行 stage。不解决根本问题，但能立刻止血。

另外两条加固：deploy 之后加一步校验，本地算 sha1、调远程 checksum 接口比对，不一致直接 fail；以及版本号里带 buildId 或 commit 短哈希，从命名上杜绝覆盖，但下游依赖要跟着改成 version range 或 BOM 锁版本。

五、我们最后选了什么

一服务一仓加 deploy 后 sha1 校验。改造两天，工作量主要在 CI 的 settings.xml 和仓库权限。止血那一周先用串行 deploy 顶着，没动业务 pom。

六、可复用的检查清单

第一，repository URL 是否只写到仓库根目录。第二，是否存在两个模块 artifactId 相同、groupId 不同。第三，deploy 日志是否只看 BUILD SUCCESS，没有 checksum 比对。第四，并行 stage 是否共用同一个 release 仓。

这四条里任意一条成立，都值得在下次流水线改造时优先处理。制品覆盖这类问题麻烦的地方不在于难修，而在于它不报错。