1、上线那天，最怕"临时改一下"发布窗口定在晚上 10 点。临上线前，有人提议："顺手把那个小 bug 也带上吧？"——于是发布内容从 5 个改动变成 6 个。上线后出事，没人知道是哪个改动引起的，回滚就退掉全部，连本来没问题的也一起退。发布的敌人不是技术，是"不可控的变更"。 本课讲：怎么把一次发布，变成一件有清单、有预案、有审批、可追溯的常规动作。2、发布 ≠ 部署先把两个词分清：部署（D …

1、从"周五晚上的惊魂上线"说起老式发布流程长这样：半夜所有人待命，运维手工敲命令，代码从 U 盘/共享盘拷到服务器，出问题立刻手动回滚——心跳加速、全员加班、出事靠人肉。而高效团队的状态是：每天发布几十次，发布是件平淡无奇的小事。 差别就在于自动化。本课讲：持续交付（CD）与环境、流水线、灰度/蓝绿发布。2、三种"持续"：CI / CD / CD这三个缩写容易混，用一句话分清：持续集成 CI …

1、"我这儿明明是好的"开发说"我在本机跑通了"，运维部署到服务器却报错。排查半天——本地装的依赖是 3.2 版，服务器上是 3.0 版。问题的根源是：代码 ≠ 制品。你的源码不是要部署的东西，构建出来的"制品（Artifact）"才是。本课讲清楚：怎么把一个项目变成一个可复现、可追溯、可部署的制品。2、构建：从源码到制品构建（Build） 是把源码 + 依赖 + 配置，编译打包成可部署的东西 …

1、功能都对，一上线就垮团队内部测试一切正常，功能没问题。上线当天搞了个活动，流量一冲——页面转圈、接口超时、数据库连接池打满，全线雪崩。另一个更隐蔽的故事：功能稳定跑了一年，某天被安全研究者发现用户列表接口能把别人的数据全拉出来（越权），数据泄露上了新闻。功能测试只能证明"做对了"，证明不了"扛得住"和"守得住"。 本课补上这两块：性能测试与安全测试。2、性能测试：问四个问题性能不只是"快不 …

1、一个"已修复"却反复出现的 Bug用户反馈："导出报表偶尔少一行。"开发看了半天，"我本地跑没问题啊"，随手标了"无法复现"就关掉。两周后同一问题再来，这次还更严重——团队才发现：根本没有稳定的复现步骤，也没人记录环境。Bug 管理不规范，修的是一个又一个"幽灵"。 本课讲清楚：一个 Bug 从发现到关闭的完整生命周期，以及怎么用数据度量质量。2、缺陷（Bug）的生命周期一个规范的 Bug …

1、"每个零件都对，装起来不转"工程师把发动机、变速箱、轮子都单独测过，各个正常。可组装成一辆车，开不动——因为接口对不上、时序错了。软件也一样：单元测试全绿，一集成全是坑。本课讲金字塔的中间层（集成测试） 和顶层（端到端测试），以及它们最容易踩的坑。2、为什么单元测试不够单元测试故意隔离了依赖（用 Mock/Fake）。这带来两个盲区：接口不一致：单元里 Mock 说"返回 {id, nam …

1、一个"手快"的代价小李写了个价格计算函数，逻辑很绕（满减、折扣、税费层层叠加）。他"手动跑了一下"发现能算对，就提交了。三周后，运营改了个折扣规则。小李改了一行，没测——结果某些订单金额算错了，直到月底对账才发现，损失不小。如果他当初写了 5 个单元测试，改完跑一下，10 秒就能发现。 本课讲清楚：单元测试怎么写，以及一种"先写测试"的方法——TDD。2、单元测试的三要素一个好的单元测试 …

1、上线前一晚的手忙脚乱周五晚上 11 点，团队准备上线。测试小张在群里喊："我点了下'忘记密码'，页面 500 了！"开发小李改到凌晨 1 点，修好了"忘记密码"。结果第二天用户反馈："登录"也不好使了——因为修复时碰到了共用的密码校验逻辑。这就是没有测试体系的典型：靠人肉点，点不全，改一处崩另一处。本课解决：测试到底在测什么？分几类？为什么是"金字塔"而不是"平铺"？一个团队该投多少精力在 …

1、"代码能跑就行"是团队的天坑先看一个熟悉的场景：团队里最懂支付模块的小王离职了。三个月后线上支付出了 Bug，没人说得清那段逻辑为什么那么绕、if 里那个魔法值 0.003 是什么。大家只能对着代码猜，改一处、崩三处。这就是知识只存在某个人脑子里的代价——巴士因子（Bus Factor）= 1：那个人一旦"上不了班"，项目就瘫一半。文档与知识沉淀的本质，不是"交作业"，而是把「脑子里的东西 …

1、敏捷不是"站会 + 看板 + 故事点"很多团队说"我们在做敏捷"，实际做的是：每天早上站 15 分钟，轮流说"昨天做了啥、今天做啥"。墙上贴一板子便利贴。每个任务估个"故事点"。然后就没了。这不是敏捷，这是敏捷的"仪式外壳"。《敏捷宣言》原文有四句话：个体和互动 高于 流程和工具可工作的软件 高于 详尽的文档客户合作 高于 合同谈判响应变化 高于 遵循计划注意措辞："高于"不是说右边没价值 …