有个Bug很明显，但当时没找到，分享一下排查过程

接口404了：

这个404的报错也不稀罕，也很好解决。

但这次花了0.5h，有点长了。

要复盘一下。

CI/CD后，新接口没生效

事情是这样的：

需要在一个老项目上新增了一个接口。

正常的拉分支，然后CI/CD:

新接口加好后，然后把新写的Feature分支合并到integration分支。

Gitlab服务器收到提交的代码后，会通过Webhook触发流水线进行发版。

看新的应用已经启动成功。

直接把新接口URL发给前端使用。然后前端把上面这个报错信息甩过来

看到这个报错，有点懵。

这个项目存在这么久了，只是加个新接口，别的啥也没做，怎么就404了？

一下子没有思路，就使用备用流水线手动重新发一次版。 备用流水线发的版本是ok的。 先解决前端阻塞的问题，问题后面再查。

Tips：没有思路时，可能是应该正确的共识出现错误了。要扩大排查的范围

根因分析

稍微空闲了点，再来查这个问题。当时想到是不是这个流水线的配置与其它不同。

比对了一下，关键配置都ok。

把疑似有问题的地方都改了，保存一下准备发版，保存界面上的东西把我震惊了：

难道CI/CD的过程中，流水线使用的不是集成分支integration？？

是的。

“系统破破烂烂”

合并代码到integration分支后，

流水线把没有新代码的master分支重新发了

master分支上没有新接口的代码，请求这个新接口时自然就404了。

解决办法就明显了，把流水线的默认分支改为integration分支就可以了。

“我们缝缝补补”

小结:第一性原理来排查问题

“任何可能出错的事情最终都会出错。”

当遇到一个问题，可以用第一性原理的思考问题的方式，把引发这种问题的各种可能性都排查一下，包括认知中的“常识”。“任何可能出错的事情最终都会出错。”

譬如今天遇到的这个404问题，原因只有一个：应用上没有这个接口的代码。 一般有这几种可能性：

1. 代码没提交
2. 代码分支被覆盖
3. 分支发错了
4. 请求的URL写错了

然后一个个排查，很快就能定位到出现错误的原因。

今天是假设分支都没错，然后就找不到原因了。

作为软件系统，任何地方都会出错的。