CI/CD流水线——从手工部署到自动化发布
周五晚上十点，群里突然炸了：线上接口超时，订单全卡住。运维登录服务器一查，原来下午有人手动改了配置没同步到另外两台机器。这种事太常见了，凡是经历过手工部署的团队，多多少少都被坑过。这篇就聊聊怎么把发布从"人肉操作"变成"流水线自动跑"，以及中间会踩哪些坑。
手工部署到底痛在哪
先把痛点说清楚，你才知道为什么要上 CI/CD。手工部署的毛病不是慢，是不稳定、不可复现。
操作全凭记忆：谁记得上次上线改了哪几个文件？换个人来就抓瞎。环境漂移更是老大难——开发机能跑，测试环境报错，生产又是一个样，说白了就是每台机器状态不一致。出了问题还没法回滚，因为是手动改的，你压根不知道上一版长什么样，只能现场抢救。再加上怕影响用户只能半夜发版，人一困出错率飙升。
这些问题堆在一起，结果就是"发版如渡劫"。CI/CD 要解决的就是把这些不确定的操作固化成代码，让每次发布都走同一条路。
CI/CD 到底在说什么
很多人把 CI 和 CD 混在一块说，其实它俩是两件事。
CI（持续集成）管的是"代码合进来之后能不能跑通"。每次有人提交代码，自动拉起来编译、跑单测、做静态检查，一旦红了立刻报警。它的价值是让问题在合并前暴露，而不是等到上线当晚才发现。
CD 有两层意思：持续交付（Continuous Delivery）指代码随时可发布，但按不按按钮看人；持续部署（Continuous Deployment）更激进，测试一过就自动推到生产。大多数团队做到持续交付就够用了，持续部署对测试覆盖率和监控要求很高，没准备好别硬上。
下面这张关系一拉就清楚：CI 是基础，保证代码可构建可测试；CD 在 CI 之上，保证产物可发布可回滚。
流水线该怎么设计
不是把步骤堆进配置文件就叫流水线。设计的时候有几条原则我建议守住。
每个阶段都要有明确的成败标准。构建成功就是产物生成、测试通过就是用例全绿，别留"差不多就行"。模糊的标准会让流水线变成玄学。失败必须快速失败，哪个阶段挂了就停在哪个阶段，别往下跑——构建都失败了还跑什么测试。
还有一条容易被忽略的：产物只构建一次，到处复用。别在测试环境构建一遍、生产环境又构建一遍，两份产物不一样就失去了意义。正确做法是构建一次产出镜像，后续阶段拿同一个镜像跑测试、做部署。最后，流水线配置本身也要和代码一起进版本库，谁改了什么、什么时候改的，都得能追溯。
主流工具怎么选
下面聊三个最常用的：GitHub Actions、GitLab CI、Jenkins。2026 年这几个仍然是市占率最高的，选型时基本绕不开。
GitHub Actions 现在 SaaS CI 里风头最盛，市占率大概三成多。最大的优势是和 GitHub 原生集成，push 上去就能跑，配置写在 .github/workflows 下的 YAML 里。它的 Marketplace 有两万多个现成 Action，装个 Node、配个 AWS 凭证基本都是拖来就用。matrix 构建能让你一次在多个 Node 版本、多个操作系统上并行跑测试，做开源库特别舒服。要注意的是计费按分钟算，macOS 跑一轮是 Linux 的十倍，Windows 是两倍，做移动端 CI 成本会涨得很快。
GitLab CI 的卖点是"一个平台全包了"。代码仓库、CI、容器镜像仓库、环境管理全在一个 GitLab 里，不用东拼西凑。配置写在仓库根目录的 .gitlab-ci.yml，概念上用 runner 执行 job，挺直观。自建 runner 的话分钟数不限，比较省；云上免费额度每月只有 400 分钟，团队稍微大点就不够用，Premium 大概 29 美元一人一月。规模一大 YAML 会变得很长，维护起来有点吃力。
Jenkins 是老牌选手，市占率还在两成八左右，生命力比很多人想象的强。它完全自托管、100% 开源免费，1800 多个插件几乎能接所有东西，灵活度最高。代价是你得自己养这台服务器：升级、备份、插件冲突全是你的活。配置用 Jenkinsfile（Groovy 写），门槛比 YAML 高一点。LTS 目前稳定在 2.504.x 系列，周更版到 2.576 左右。
一拉就清楚：项目在 GitHub 上、要快上手，选 Actions；已经在用 GitLab、想要一站式，选 GitLab CI；有强隔离和定制需求、能养运维，选 Jenkins。三者不互斥，大厂里 Jenkins 跑重型任务、Actions 跑轻量验证的组合也很常见。
一条完整的流水线长什么样
下面用一个 Node 服务的例子，把"提交→构建→测试→部署→回滚"串起来，看看每一步在干什么。
代码提交触发流水线。第一步是 lint 和单元测试，跑挂了直接红灯，连构建都不往下走。这步最便宜，能挡掉大部分低级错误。
构建阶段把代码打成 Docker 镜像，打上 Git commit 短哈希做标签，推到镜像仓库。注意标签别用 latest，latest 是个坑，出了问题你根本不知道线上跑的是哪次构建。用 commit 哈希或语义化版本，一查一个准。
构建完跑集成测试和安全扫描。集成测试起一个临时环境把镜像跑起来，验证接口能不能通；安全扫描用 Trivy 这类工具扫镜像里的已知漏洞。这俩过了，镜像才算合格。
部署阶段先上预发环境，跑一轮冒烟测试，确认核心链路没问题，再灰度推到生产。灰度别一次全量，先放 10% 流量观察几分钟，没问题再放大。
回滚是最后一道保险，也是最容易省略的一道。道理很简单：上线前先确认能回滚。一旦新版本指标异常，一键切回上一个镜像标签就行。因为镜像标签是固定的，回滚就是换标签、重新调度，几秒钟的事。
踩坑和最佳实践
跑过几条流水线之后，有几个坑几乎人人踩过。
密钥别写进配置文件。哪怕私库也别赌，用 Actions Secrets、GitLab Variables、Jenkins Credentials 这类机制注入，泄一次密你就知道疼了。缓存要用对，依赖每次都重新装，流水线能慢出一杯咖啡的时间，把 node_modules、Maven 仓库这类东西缓存起来，构建时间能砍掉一大半，但缓存键要带上依赖文件 hash，不然缓存了旧依赖更坑。
流水线别越跑越长。团队一大，流水线里塞的东西越来越多，最后跑一次二十分钟，没人愿意等。把耗时的端到端测试拆出来单独跑，主流水线保持五分钟内出结果，体验会好很多。生产部署永远要有审批，自动化不等于全自动，推到生产这步加个人工确认，能挡住手滑和半夜脑子不清醒的操作。
最后说一句，CI/CD 不是装个工具就完事的工程，它更像是团队协作习惯的重塑。工具一两天能搭起来，但让每个人习惯"提交即验证、发布走流水线"，往往得磨上几个月。先把最痛的那个环节自动化掉，跑顺了再逐步往前推，比一上来就搞大而全要靠谱得多。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/wjjzhbb/article/details/164112309
