1. 先从概念说起CI/CD到底是什么写这个题目之前我翻了不少团队的实际交付流程发现一个挺有意思的现象很多人嘴上挂着“CI/CD”但被问急了会发现他们其实把持续集成、持续交付、持续部署这三件事混在一起。甚至有的团队说“我们上了CI”实际只是跑了个脚本把代码拉下来执行一下编译其他啥也没干。CI/CD是一个实践集合不是某个工具也不是某条流水线。拆开看的话CI是持续集成Continuous Integration意思是开发者的代码变更频繁地合并到主干每次合并都自动触发构建和测试目的就是尽早发现集成问题。CD有两种解读一种是持续交付Continuous Delivery保证代码随时处于可发布状态但发布动作由人来按按钮另一种是持续部署Continuous Deployment连按钮都省了通过所有测试的代码自动上线。我一般喜欢用一个类比来解释CI是流水线上每道工序的质量检查你每装一个零件都要检查一下发现问题当场返工CD则是把从质检合格到装箱发货的流程全部自动化。传统模式下你攒一个月代码再集成最后一天突然冲突爆炸那就是在赌人品。CI的意义就是把“最后一天的灾难”拆散到每一天去消化每次变更只处理一点摩擦成本小得多。对于刚开始接触这个领域的同学还有个容易踩的误区以为CI/CD只是“自动化跑脚本”。其实自动化只是手段真正的核心是“快速反馈”和“可重复的发布流程”。如果你只是把构建脚本放到服务器上手动点一下那不算CI/CD那叫“用电脑代替人跑命令”区别在于前者有明确的阶段划分、结果反馈和质量门槛。这篇文章我会结合自己实际搭建流水线的经验把CI/CD从理论到落地拆开讲清楚包括工具选型、流水线设计、实际配置、常见坑点。适合正在规划自动化交付的团队负责人、开发工程师、运维工程师以及刚准备入门DevOps的同学参考。2. 为什么一定要上CI/CD从手工部署的痛点说起很多团队在只有两三个开发、一个月发一次版的时候觉得CI/CD是多余的“脚本写一下不就行了”。这话有一定的冷幽默成分在——脚本写一下其实就是CI/CD的雏形。真正让你下定决心上的往往是某次手工部署事故。2.1 手工部署的经典翻车现场说个我自己遇到过的例子。某次上线前测试环境明明验证过了但生产环境部署后页面直接白屏。查了一下午最后发现是同事在生产服务器上手动执行错了命令把旧包覆盖了新包但又因为“看着像新文件”没人察觉。这种“环境漂移”问题在手工操作下几乎无法根治。类似的故事还有A同事在本地改了依赖版本但没提交lockfileB同事部署时拉下来重新解析依赖解析出了一套新的传递依赖功能表现完全不一样或者DBA手动在线上库执行了两条SQL结果没有记录在变更脚本里下次从备份恢复时这两条变更就丢了。你会发现这些问题的共同点是“人执行、人记忆、人确认”。只要这几个环节存在于流程中就永远有概率出错。而CI/CD要做的就是把这些步骤变成“机器执行、机器记录、机器确认”。2.2 自动化带来的实际收益把手工操作变成流水线之后第一个直观收益是“部署变得无趣了”。听上去好笑但“无趣”恰恰是稳定性的代名词。每次部署都走同一条流水线同一套脚本同一个基础镜像甚至同一个输出日志格式问题特征就开始变得可归纳哪一步挂了看看日志就知道大概方向。第二个收益是反馈速度。没有CI的时候一次合并引发的编译错误可能要等第二天集成时才发现。有了持续集成每次push后的十分钟内就会告诉你这次变更有没有破坏现有功能。连续反馈的前提是流水线本身要快我见过有的团队流水线跑一个多小时那基本等于没有CI人都懒得看结果了。第三个收益是“发布能力”的扩展。你可以在一周内发布十次也可以随时回滚到任意一个已知良好版本。这在手工操作时代是不可想象的——你可能需要翻聊天记录找上次的发布包在哪。所以不要只把CI/CD当成“DevOps团队的事”。它本质上是一种工程管理手段让交付过程可度量、可重复、可回溯。3. 工具选型与架构设计别一上来就整全套CI/CD的工具圈已经卷了十多年想找一个“没有竞品”的工具几乎不可能。从老牌巨头Jenkins到云原生时代的GitHub Actions、GitLab CI、CircleCI、Drone、Tekton各有各的拥趸。但聊选型之前我更想说一句工具从来不是最重要的重要的是你对流水线的理解。3.1 主流工具横向对比我根据实际使用频率把常用的几类工具列一个对比。工具适合规模维护成本核心优势主要短板Jenkins中大型、高度定制场景较高插件生态最丰富任务自由界面老气配置分散维护费劲GitLab CI中小团队到大型团队中和GitLab代码库深度绑定依赖Runner自建Runner需维护GitHub ActionsGitHub用户低云托管生态市场丰富私有仓库额度有限平台锁定制CircleCI中小型团队低配置简洁缓存机制成熟收费版较贵免费额度有限Tekton/K8s原生云原生场景较高可运行在K8s内弹性强学习曲线陡峭抽象层级多我的观点是新项目优先看你的代码托管在哪——代码在GitLab就首选GitLab CI在GitHub就首选GitHub Actions。这一个选择能帮你省掉很多额外的系统集成工作量。如果你手上维护着极其复杂的历史包袱比如几十个不同语言栈的项目、大量自定义脚本、需要手动触发某些构建、跟企业内部系统强耦合那Jenkins可能还是最适合的。Jenkins这种“自由风格任务”的自由度在这么多工具里依然是天花板级别。3.2 流水线设计的基本套路不管用什么工具流水线的骨架大体一致。我习惯按照“阶段”来拆拉取代码、安装依赖、执行测试、构建产物、发布归档、部署环境。拉取代码触发方式可以是push、merge request、定时任务或者手动触发。安装依赖根据项目类型执行npm install、pip install、mvn package等操作。执行测试单元测试、集成测试、静态代码分析、覆盖率统计。构建产物编译打包生成可部署的jar、docker镜像或静态文件包。发布归档把构建好的产物上传到制品仓库比如Nexus、Harbor、OSS。部署环境将产物部署到测试环境、预发布环境或生产环境。设计流水线的时候有两条铁律第一条测试不通过绝不允许继续往下走。你可以把测试挂件挂在构建前面质量门禁这一关一定要硬。哪怕团队里有人抱怨“测试太慢了先放过去吧”也要顶住。这时候慢一点是在保护生产环境。第二条一个阶段只做一件事尽量别在跑测试的阶段顺手改服务器配置。尽量让每个阶段职责单一定位问题的时候才能快速锁定日志。所以落地CI/CD的第一步不是打开配置文件写YAML而是先想清楚“你希望哪些步骤被自动化、哪些步骤必须人工介入”。比如生产环境的部署你可以让流水线自动跑完构建和测试但最终点击上线按钮的是人。这其实就是持续交付和持续部署的界线由你的团队对风险的容忍度决定。4. 实操从零搭建一条能用的流水线4.1 项目结构准备先要让机器觉得可重复我最看重流水线的一点是可重复性。如果这条流水线在周一跑完周三再跑同一份代码得到的结果完全不同那它就不是一条好的流水线。要实现可重复第一步就是消除对“当前环境”的依赖。最常见的手段是容器化。我用GitLab CI举例Runner执行任务的时候会拉取一个镜像在这个镜像里跑你的构建命令。这就意味着你的构建环境是预定义的不管是tomcat、node还是python所有依赖都写在镜像里而不是靠某个开发者在自己的机器上“装好了”。第二步是锁依赖版本。前端项目要有package-lock.json或者yarn.lock后端Maven项目要确保使用固定版本插件最好把整个依赖树快照保存下来。这个看似啰嗦的步骤会帮你躲掉90%的“在我电脑上是好的”问题。第三步是保证流水线的脚本要从仓库里取。这里我见过一个反模式把一段部署逻辑写在Jenkins的“系统管理”里代码库里反而没有。如果换台服务器重新搭建Jenkins那这段逻辑就消失了。正确做法是所有脚本、配置都跟随代码库走。这样才能保证“从仓库到生产环境”的每一步都是可追踪、可审计的。4.2 .gitlab-ci.yml核心配置拆解下面我用一个比较典型的Node.js项目来演示配置。假设项目结构是my-service/ ├── src/ ├── test/ ├── package.json ├── Dockerfile └── .gitlab-ci.yml.gitlab-ci.yml最少要包含这几个关键部分stages定义阶段、每个Job的script、以及runner标签。一个可用的基础配置长这样stages: - install - test - build - deploy variables: NODE_ENV: production NPM_CACHE: /cache/npm cache: key: $CI_COMMIT_REF_SLUG paths: - node_modules/ - .npm/ install: stage: install image: node:18-alpine script: - npm ci --prefer-offline tags: - docker only: - merge_requests - main - tags artifacts: paths: - node_modules/ expire_in: 2 hours这里重点解释几个容易被忽略的点。npm ci和npm install的区别在于npm ci会严格根据lockfile安装依赖不会自己解析更新版本适合CI环境。如果你用npm installCI跑出来的依赖版本和本地可能不一样这就是“构建结果漂移”的来源。cache关键字可以把node_modules缓存到Runner上下次构建直接复用速度会快很多。但是很多人踩过坑缓存了过期的依赖代码锁文件变了但缓存没失效导致莫名奇妙的旧依赖参与构建。所以我的习惯是缓存key里加上分支信息并且当package-lock.json变化时自动跳过缓存。4.3 构建、测试、部署三个阶段紧接着上面的基础配置为了不让流水线变成一条“单点脚本串行”我一般再拆分test和build阶段。测试阶段的完整样子test: stage: test image: node:18-alpine script: - npm run lint - npm run test:unit - npm run test:coverage artifacts: when: always reports: coverage_report: coverage_format: cobertura path: coverage/cobertura-coverage.xml expose_as: coverage这里有两个关键点第一即使测试失败我也想看到测试报告所以设置了when: always。这能帮助快速定位是哪些case挂掉了不用去翻原始日志。第二reports选项可以把JUnit或Cobertura格式的测试报告展示到MR页面方便在合并请求上直接看覆盖率。这一招对提升团队的代码质量意识特别有效——只要覆盖率下降了流水线就变红不用你催。构建阶段我通常用Docker来做因为镜像本身就是产物后续部署就是拉镜像跑容器环境差异被彻底抹平。build: stage: build image: docker:20.10 services: - docker:20.10-dind script: - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA . - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA only: - main - tags这段其实包含了两个知识点。一个是用$CI_COMMIT_SHA给每次构建的镜像打上唯一标签这样生产部署时能精确知道跑的是哪一次提交的代码回滚时也能精确找到“上一个好版本”。另一个是“docker in docker”的Service机制。Runner所在的容器里要执行docker build命令本身必须有一个可用的docker daemon。让Runner容器通过service方式连接到一个特权docker daemon容器是最常见的做法。部署阶段最稳妥的是用Kubernetes部署。如果没有K8s也可以用明文的脚本形式但我不太建议新手在初期就把生产部署的SSH密钥写在流水线里。常见的折中方案是流水线负责把镜像推到私有仓库然后通过SSH远程执行一条命令让服务器自己拉镜像重启容器。deploy-prod: stage: deploy image: alpine:3.16 before_script: - apk add --no-cache openssh-client script: - ssh -i $PROD_SSH_KEY -o StrictHostKeyCheckingno root$PROD_SERVER docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA docker service update --image $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA myservice environment: name: production only: - tags when: manual这里特别说明两点。when: manual意味着只有人工点击才会触发这个Job这是持续交付的典型设计。生产部署这种动作即使流水线完全具备自动部署的能力一般也会留一道人工确认关卡尤其是对面向用户的系统。environment关键字适合跟GitLab的环境面板联动谁在什么时间部署了哪个版本一清二楚出问题回滚也有依据。5. 常见问题排查与避坑指南这几年帮不少团队修过流水线大部分问题不是工具不会用而是概念上的偏差和习惯上的疏忽。我把最经典的几个问题整理出来当成速查表供参考。5.1 构建环境不一致本地没问题线上就崩这是遇到频率最高的问题。本地跑得好好的推上去CI挂了第一反应往往是“CI环境有问题”。但真相多数时候是“本地环境有自己的隐藏依赖”。规避办法很粗暴用容器镜像钉死构建环境用lockfile钉死依赖版本。如果你两者都没做那你的CI/CD本质上还是“手工部署的手工版”。还有个小技巧在跑构建之前先执行一个“清场”步骤比如删除workspace旧目录、清理npm缓存避免上一轮构建残留影响本次结果。虽然听起来基础很多事故还真就是残留文件导致的。5.2 缓存策略加速和准确之间的平衡缓存能显著加快流水线速度但代价是可能存在脏缓存。我最常用的策略是“按分支分缓存key”然后“改依赖时刷缓存”。具体的YAML写法因工具而异。比如GitLab CI里可以用cache:key:files来指定当某个文件改变时自动生成新缓存cache: key: files: - package-lock.json paths: - node_modules/这个配置的意思是只要package-lock.json没变就复用同一个缓存一旦它变了自动生成新缓存。这样既快又不容易出脏数据。Jenkins里可以用“流水线插件自带的缓存目录”或者直接通过caches配置思路一样。5.3 权限与密钥别把密码写进YAML把服务器密码明文写在.gitlab-ci.yml里就跟把银行卡密码写在银行卡背面一样。正确做法是使用工具自带的“变量/凭据机制”把敏感信息放到项目的CI/CD变量里然后在脚本中通过$VARIABLE引用。GitLab CI的变量里有两种形式普通变量和掩码变量。掩码变量在日志里会显示为[MASKED]这对防止密钥泄漏很关键。Jenkins则用Credentials Binding插件运行时把凭据注入环境变量避免直接在脚本中暴露。再补一条安全建议不要在Runner上共享同一个SSH Key。最好搞一个专用的部署账号并且这个账号权限越少越好只能执行应用需要的几条命令。5.4 部署失败与回滚先想好退路再上生产部署失败的典型特征是“验证完测试才发现生产挂了”。但真正的问题在于你的回滚策略是什么。如果回滚方式只是“重新部署上一个版本”那就需要确保上一个版本还能取到、还能跑。我建议的流程是每个构建产物至少保留N个版本N根据你的存储成本定比如最近5个生产环境使用不可变标签比如镜像tag用commit SHA不覆盖部署脚本里带上“回滚到上一个版本”的功能不要单独手工处理另外回滚本身也应该走流水线。在环境面板里点“回滚”其实就是在重新部署那个版本。这比上服务器敲命令要安全得多至少操作有记录步骤可复现。5.5 流水线跑的越来越慢这个问题属于典型的“摸着石头过河之后掉坑”。一开始流水线可能两三分钟就完成了跑了几个月后变成二十多分钟。原因通常是测试代码越写越多但没做并行化依赖缓存失效严重每次都全量下载构建机器的清扫不彻底执行历史垃圾堆积大量的“全量单元测试”被塞进MR验证流程而实际上很多用例没必要频繁跑针对并行化GitLab CI支持parallel关键字可以让同一个Job在多个Runner上并行执行再通过needs控制阶段间的依赖关系。GitHub Actions里则用矩阵策略。我个人的习惯是单测类、构建类、集成测试类用三个不同的Job并让它们尽量跑在同一个Runner上以复用缓存。跨Runner的并行反而可能因缓存不共享导致重复安装依赖得不偿失。6. 一些真正想告诉你的经验写到这里我估计你也看出来了CI/CD本身不是什么黑魔法它就是把成熟工程实践中“必须做”的事用工具固化下来。但工具只是最基本的真正难的是改变团队习惯。流水线跑通了不代表团队就能持续交付。很多人搞了一套自动化流水线结果每次发版还是大家在群里喊“有没有人看到刚才那个部署任务过了没”“测试环境依赖是不是又没更新”。这种状态说明自动化工具没有内化到工作流里。我的建议是先把流水线跑通一个最小闭环。哪怕就是“代码合并后自动跑一下编译和单测”也比没有强。不要一上来追求Kubernetes集群、灰度发布、自动化回滚这种全套高级姿势。等你把基础闭环跑稳了再一步步加复杂度。有几个小习惯我至今觉得特别有用顺手分享给你第一提交信息里写清楚“这件事解决了哪个问题”这样流水线的触发记录能直接对应到需求背景。翻历史流水线的时候你会感谢当时的自己。第二每个阶段结束后都把关键产物测试报告、构建日志打包保存下来。哪怕觉得“用不上”三个月后生产环境出问题查原因的时候这些存档可能是唯一的救命线索。第三流水线的每一步最好都产出明确的“前后对比”比如覆盖率从85%变成了82%部署包大小从2.3MB变成了2.5MB。有对比才有预警数字不会说谎。我自己做过最值得的一件小事是为团队搭了一套“合并前必跑流水线”规则很简单不跑完流水线合并按钮永远是灰的。刚开始有人觉得麻烦后来有人离了这条流水线都不敢合并。因为大家都知道了流水线不是“多了一道流程”而是“多了一层保护伞”。CI/CD这条路没有终点团队在变、技术栈在变、负载在变流水线也得跟着演进。但方向是清楚的让交付这个过程逐渐变得不需要“赌运气”。