😂 IT段子

自动化的收益在第一次故障时才体现。我抬起头看了看周围，大家都一样。我发现这个部署脚本依赖了本地的一个文件。好在最后有惊无险

发布最怕的不是失败，是失败得不明确。我想了想自己这些年，好像确实如此。我加了 try-except，先让流水线绿起来再查根因。办公室安静得能听见键盘声

周一早上发版，周五下午封版，周报里写"本周进行了例行发布"。我想反驳，但发现他说得对。我在心里给这次的发布写了一句总结，整体顺利。这条经验值直接拉满

发布审批流程走了五个人，问题还是发出去了，流程很完善，就是没人看。我盯着屏幕，觉得这才是我的一天。我发现这个部署方式会导致短暂的不可用。幸好之前留了备份

流水线重试三次都失败，第四次没改任何东西就成功了，我把这个现象命名为"构建玄学"。我盯着屏幕沉默了十分钟。我在心里给这次的发布留了足够的观察时间。我把这条经验写进了团队 wiki

周一早上发版，周五下午封版，周报里写"本周进行了例行发布"。我愣了两秒，然后继续敲代码。我加了 try-except，先让流水线绿起来再查根因。幸好之前留了备份

CI 流水线绿了不代表没问题，只能代表测试没测出来。我想了想自己这些年，好像确实如此。我把这个流水线的超时时间调大了，慢构建不再被掐。第二天这个方案就变成了团队标准做法

周一早上发版，周五下午封版，周报里写"本周进行了例行发布"。我听完沉默了，因为太真实了。我打开流水线日志一页页翻，最后在倒数第二行找到了报错。真香定律准时生效

这个部署脚本里有硬编码的地址。我拉了个小群，把相关同学都叫了进来。我发现这个流水线的通知只发到了一个人的邮箱

制品库满了导致发布失败，清理制品的时候把上周的版本也清了。我把这个流水线的分支策略配好了，feature 不触发发布。我把这条经验写进了团队 wiki