ci-cd

7 posts

你的 API 在生产环境崩溃,是因为 CI 在测代码,而不是 contracts

大多数 CI 流水线能捕获语法错误和逻辑 bug,却漏掉了真正拖垮生产环境的 API contract 破坏。以下是修复方法。

我们团队中每一个进入生产环境的 API 破坏都通过了 CI。每一个。单元测试是绿的,集成测试套件通过了,部署发出后,Slack 消息就开始刷屏了。 问题不在于我们没做测试。问题在于我们测错了东西。大多数 CI 流水线验证的是代码能否运行,却不验证生产者与消费者之间的 API contract 是否仍然完整。…

你的文学化程序在 CI 能无需你参与就完成 tangle 之前都是坏的

Literate programming 承诺单一事实来源,但手动的 weave 和 tangle 步骤会破坏 CI/CD 流水线。以下是如何自动化提取和文档生成,使 Markdown 文件保持规范。

如果你的构建流水线必须等你打开终端输入 才能运行,那你就没有文学化程序。你有的只是一本绑着编译器的日记。 文学化编程的全部意义在于散文和代码共享单一事实来源。Markdown 文件就是产物。其他一切——可执行源码、渲染后的文档、测试文件——都是派生的。派生产物属于 CI,不属于你的工作记忆。 问题不是 CI 能不能…

编译器检查语法,测试应该检查架构。

大多数团队把架构规则写在维基里。这里介绍如何把它们写成可执行的测试,当你的依赖图发生漂移时让 CI 挂掉。

你的测试套件验证了 在输入正确时返回 42。但它没有验证 是否被允许导入 。编译器对两者都满意。你的单元测试对两者都满意。但其中之一是架构违规,六个月后会让你花上一周时间来重构。 这就是盲区。我们为逻辑写测试,却假设结构会自行管好。并不会。…

你的领域层引用了 Postgres。你的 CI 却视而不见。

整洁架构的图在白板上看着很美。本文介绍如何在构建流水线中强制执行依赖方向,让领域代码永远无法触及基础设施。

团队里有人刚在 里引入了 。PR 编译通过。测试全绿。代码审查长达三百行,却没人发现。 三个月后,你想把领域逻辑抽成一个共享包。做不到。它依赖了 Postgres 的类型、连接池逻辑,以及一个只在单体应用里存在的自定义驱动封装。白板上那套同心圆架构图,此刻成了笑话。 这就是没有自动化 enforcement…

变异测试需要跑4小时。团队到底怎么在CI里用它?

大多数团队不会每次提交都跑完整的变异测试套件。以下是工程团队如何在不破坏构建流水线的情况下,真正把变异测试集成进CI的做法。

如果你的变异测试套件需要跑四个小时,恭喜你。你证实了大家早就怀疑的一件事:你的测试套件存在漏洞。 你不可能每次 push 都到 CI 里跑这个。没有哪个团队会这么干。问题不在于你能否承受每次提交花四小时,而在于你能否承受带着“测试通过但实际上什么也没验证”的代码上线。…

AI Codebase 的确定性护栏

人工审查不一致,AI 审查更不可靠。AI 生成 codebase 唯一可扩展的防线是确定性 enforcement:让构建失败的规则,而非被忽视的建议。

对 AI 生成代码的标准建议是"仔细审查"。 这个建议正确但在规模化时毫无用处。 开发者审查 AI 输出时,在精力充沛、熟悉领域且没有时间压力的情况下能发现问题。在其他所有条件下——而这是大多数情况——问题会漏过。 用 AI 审查者来发现 AI…