北京
周四晚上11点，老张盯着屏幕上的报错日志，第三次回滚了今晚的发布。队里没人敢睡。同样的代码在预发环境跑得好好的，一上生产就挂了。这不是个例——很多团队不是不会写代码，而是每一次上线都像拆弹。后来他们做了一件事：把所有手动操作变成一条自动化流水线，从此每天发布几十次，再没在深夜出过事故。
这条流水线的核心逻辑很朴素：让每一次代码提交自动证明自己安全，一路绿灯跑到生产环境，不需要人蹲守。下面还原一下这条流水线是怎么搭建起来的。
第一步是持续集成，也就是CI。每当有人推送代码或发起合并请求，流水线立刻启动，按从快到慢的顺序跑检查。最先上场的是代码规范和格式检查，几秒钟就能揪出低级错误；接着是类型检查，如果你用TypeScript，这一步能在测试运行之前拦截大量类型不匹配的bug；然后轮到单元测试和集成测试，这是主力安全网，必须够快，否则开发人员会绕道走；最后才是构建，证明整个应用能成功编译并打包成一个可部署的制品。这个顺序很关键：快检先行，别让一个格式错误排在测试套件后面干等十分钟。把整条CI控制在十分钟以内，否则就没人认真看了。
接下来是一个容易被忽略的细节：构建一次，然后把同一个制品推进到所有环境。很多团队犯的错是，为预发环境重新构建一次，为生产环境再构建一次。正确的做法是只构建一个制品——Docker镜像就很合适——让这个完全不变的镜像从预发一路走到生产。既然它在预发通过测试，那么进入生产的字节流一模一样，“预发没问题，生产出问题”这类玄学bug就彻底消失了。
持续交付这一步，核心是把无聊的流程自动化，把可怕的操作关进笼子。对大多数团队来说，代码合并到主分支就应该自动部署到预发环境；生产发布可以留一道手动确认，也可以等测试覆盖率足够自信后完全自动化。关键是，部署必须是一个脚本，而不是靠某个人半夜对着操作手册敲命令。
为了让糟糕的版本不至于一上线就炸翻全部用户，流水线里得塞进安全发布策略。一种方式是蓝绿部署，始终保持旧版本在线，新版本发布后一旦出问题，瞬间切回旧版本；另一种是金丝雀发布，先让一小部分流量打到新版本上，盯着监控指标看，没异常再逐步放大。无论哪种，目的都一样：让爆炸半径尽量小。
回滚能力被提到了一个很高的位置。一切都会失败，区别只在于恢复速度。回滚不应该是一堆繁杂的操作，而应该是一颗按钮，一个经过演练的单一命令，能在几秒钟内退回到上一个已知正常的版本。如果回滚操作吓人或者太慢，出问题时人就会犹豫，而犹豫的时候最要命。
最后是两条铁律：永远不要把密钥写进镜像或日志，在运行时从密钥管理服务注入；保护好主分支，要求所有变更必须通过检查并审核后才能合并，让流水线成为通往生产的唯一路径，不允许任何人绕过。这两条规则能防止大部分人为事故。
你不必从第一天就把全套流水线搭完整。可以从最小的闭环开始：每次合并请求自动跑测试，再加一个一键部署命令。随着业务压力变大，再逐渐加入金丝雀发布和更丰富的监控。哪怕只是最精简的配置——自动化测试加上自动化部署——也比人工上线安全一个量级。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
