代码合并到主分支，十分钟后测试环境自动更新，半小时后线上生效，中间没人手动打包。这套流程就是常说的 ci cd。三个字母看着抽象，拆开就是自动构建、自动测试、自动发布三件事。
CI 管的是合并之后
CI 是持续集成。开发把代码推到 Git 仓库，流水线自动拉代码、装依赖、跑单元测试、做静态检查。任何一步失败就拦住合并，避免有问题的代码进主干。关键在频繁提交、小步合并，别攒一周的改动一次推。测试覆盖率不用追求数字好看，核心链路有覆盖更实际。流水线跑在独立环境里，能暴露「我本地是好的」这类问题，依赖版本、环境变量、数据库连接都和开发机不一样。
CD 管的是交付和部署
CD 可以指持续交付，也可以指持续部署。持续交付是自动打好包、部署到预发环境，上线前留一个人工确认；持续部署则连生产也自动发。多数团队从持续交付起步，等监控、回滚、灰度都成熟了再往后走。数据库变更、缓存清理这类步骤，要单独写成可重复执行的脚本。灰度发布先放一小部分流量，观察十几分钟，指标正常再扩大范围，比一次性全量稳妥得多。
一条流水线长什么样
- 触发：推到功能分支跑测试，合并到主分支触发构建。
- 构建：编译、打包镜像，版本号用提交哈希，别用 latest。
- 部署：先灰度一台，观察错误率和延迟，再全量。
- 回滚：保留上一版镜像，出问题一条命令切回去。
流水线红了先看哪一步
构建失败先看日志末尾二十行，编译错误、依赖下载超时、测试断言失败，处理方式完全不同。测试偶发失败要单独标记，别养成点重跑的习惯，问题会越积越多。部署失败先确认是连不上目标机，还是健康检查没通过，前者查网络和密钥，后者看应用日志。
常见工具是 Jenkins、GitLab CI、GitHub Actions，配置文件跟着代码走。密钥放平台的环境变量里，别写进仓库。ci cd 不是装个工具就完事，测试可信、回滚可用，流水线才有人敢用。小团队不用一上来就搞全自动，先把跑测试和打包做顺，再逐步加上部署，维护成本才压得住。