不出意外的话你最近一定被“CI/CD”这个词刷屏了。但搜了一堆资料要么是概念讲得云里雾里要么是上来就甩一大段 YAML看完还是一脸懵。我自己最开始接触 CI/CD 时也是这样总觉得这东西是“大厂专属”离我很远。直到第一次用 Jenkins 自动化部署把项目推上线才突然明白它本质上就是给开发流程配了一位“流水线工人”你只需要告诉他每一步做什么他就会老老实实地帮你去拉代码、跑测试、打包、上传服务器。这篇文章我打算用最贴近实际的方式把自动化 CI/CD 的入门路径讲透适合刚接触自动化测试、自动化部署的开发者也适合想给团队搭建自动化体系但不知道从哪下手的运维或测试同学。我在这篇文章里不会讲太多虚的全部按我自己实操的经验来。先帮你理清 CI/CD 整体是怎么运转的再带你亲手搭一套能用的自动化流水线。热词里提到的 Jenkins 自动化部署、GitLab Runner、接口自动化、Webhook 触发这些我都会覆盖到。别怕跟着一步步来你也能拥有自己的自动化流水线。1. 自动化 CI/CD 的整体设计与方案选型1.1 CI/CD 到底在自动化什么先别急着聊工具你得先搞清楚流水线上要跑的活是什么。CI持续集成和 CD持续交付/持续部署其实是两件事但通常被合起来用。CI 管的是“从代码提交到代码合并这一段的自动化验证”比如每次有人 push 代码自动触发构建和测试保证你提交的代码不会把别人的功能搞挂。CD 管的是“验证通过之后怎么把产物送出去”可以是手动点一下发布也可以是完全自动地部署到服务器。很多人的误区在于以为 CI/CD 就是写一个“构建加部署”的脚本。实际上一个成熟流水线里还会塞进代码静态检查、单元测试、接口自动化测试、镜像构建并发往仓库、以及多环境部署。热词里出现频率很高的“自动化测试”和“接口自动化”其实是 CI 阶段的核心环节。我见过不少团队流水线里的测试就只跑个pytest跑完就算数根本没有把测试结果和报告归档。结果出问题时根本不知道是代码变更导致的还是环境不稳定导致的。所以 CI/CD 自动化的第一个目标是让“验证”过程可重复、可追溯而不是简简单单按个按钮。再往下说CD 自动化的核心目标是“用同一套流程交付到任何环境”。以前手动部署开发环境一套命令测试环境一套命令生产环境再换一套哪天手一抖漏了一条配置排查到天亮。自动化之后你把环境差异抽象成参数和配置文件流水线在哪个环境就注入哪套变量打包产物保持一致很少再出现“在我机器上明明没问题”的尴尬。这也是为什么容器化会成为 CI/CD 的好搭档因为镜像天然就是“一次构建、到处运行”的单元。1.2 主流工具对比Jenkins、GitLab CI、GitHub Actions 怎么选选工具之前先盘一下你的使用场景。是自己在本地玩公司代码托管在 GitLab还是项目托管在 GitHub不同的代码托管平台往往决定了你最顺手的 CI/CD 工具。Jenkins老牌、插件多、搞 Java 项目的人用得最多。优点是可以自建 Master-Slave或者 Controller-Agent架构节点多了可以跑大规模并行任务。缺点是界面偏老维护成本偏高首次配置 Pipeline 的“坑位”多。GitLab CI和 GitLab 代码仓库天然集成写好.gitlab-ci.yml放仓库根目录就能跑。用的是 GitLab Runner 作为执行器。特点是配置和仓库版本绑定分支策略清晰业绩不错。GitHub Actions和 GitHub 仓库极简集成市场上有大量现成的 Action适合开源项目和中小型项目。它不用自己维护服务端跑在 GitHub 的云服务器上对个人项目非常友好。除了这三个你还会看到 Drone、Travis CI、CircleCI 等但思路大同小异。我的建议是如果公司已经有 GitLab别折腾 Jenkins 了直接用 GitLab CI省去 Webhook 的额外配置如果代码托管在 GitHub就用 GitHub Actions如果你们团队对自建运维有硬需求Jenkins 依然稳妥。我见过不少初学者一上来就搭 Jenkins装一堆插件然后又配一堆 Agent绕了很多弯。我建议如果你只是想先跑通流程直接选和代码仓库同生态的工具至少能少踩一半的坑。工具没有绝对的好坏只有适不适合当下的场景。你选好工具之后再想清楚流水线要跑哪几个阶段。2. 核心细节解析与 Pipeline 基础2.1 Pipeline 的骨架Stage、Step、Agent任何 CI/CD 工具最后落到配置里无非就是几个概念Agent在哪个环境执行、Stage分几段、Step每段里执行什么命令。以 GitLab CI 为例一个最简单的流水线长这样stages: - build - test - deploy build-job: stage: build script: - echo Building the app... - npm install - npm run build test-job: stage: test script: - echo Running tests... - npm test deploy-job: stage: deploy script: - echo Deploying to server... - scp dist/* userserver:/var/www/html/这段配置里stages定义了阶段顺序每个 Job 通过stage字段指定自己属于哪个阶段。同一个阶段的 Job 可以并行跑不同阶段有先后依赖。这一点很关键很多人喜欢把所有命令堆在一个 Job 里表面上也能跑但一旦失败你分不清是构建问题还是测试问题而且也没法复用“构建产物”。把流水线拆成多个阶段每个阶段只干一件事排查问题会轻松很多。Stage 的生命周期里还有几个隐藏点。比如 Stage 之间如何传递产物。GitLab CI 提供artifacts关键字Jenkins 里用stash/unstashGitHub Actions 里用upload-artifact。构建阶段生成的编译产物、测试报告、安装包如果后续阶段要用必须显式保存和取用而不是跑完一个 Job 就什么都没了。很多人一开始忘记配置 artifacts导致测试阶段又要重新构建一遍白白浪费时间。再来说 Agent。Jenkins 里面叫 AgentGitLab CI 里叫 Runner核心功能都是给流水线提供执行环境。你可以让 Agent 跑在物理机、虚拟机或 Docker 容器里。我强烈建议把每个阶段的执行环境做成镜像比如构建 Node 项目用一个带 Node 的 Docker 镜像构建 Java 项目用一个带 Maven 和 JDK 的镜像。这样一来不管你本地环境怎么折腾流水线上跑到的都是干净一致的环境彻底告别“在我机器上是好的”。2.2 声明式与脚本式配置不是越灵活越好如果你用 Jenkins会遇到两种 Pipeline 写法Declarative Pipeline声明式和 Scripted Pipeline脚本式。新手很容易被网上的 Demo 带偏一上来就写一堆stage包裹的 Groovy 脚本。我自己强烈推荐从声明式开始因为它结构强制阶段清晰语法有限但够用不容易把流水线写成“面条脚本”。下面是一个 Jenkins 声明式 Pipeline 的骨架pipeline { agent any stages { stage(Checkout) { steps { checkout scm } } stage(Test) { steps { sh pytest tests/ -v --junitxmlreport.xml } } stage(Build) { steps { sh docker build -t my-app:${BUILD_NUMBER} . } } stage(Deploy) { steps { sh docker push my-app:${BUILD_NUMBER} } } } }注意几个细节。agent any表示任何 agent 都能执行但如果是正式项目最好指定agent { docker { image python:3.11 } }这类环境。checkout scm是 Jenkins 自动从代码仓库拉取当前分支的命令不用手动写git pull。${BUILD_NUMBER}是内置变量每次构建递增适合作为镜像标签。声明式的缺点也有就是不够“编程友好”比如循环和条件分支写起来比较笨。如果你的流水线真的有复杂的逻辑那再考虑脚本式。但至少入门阶段别让灵活性毁掉可维护性。2.3 环境变量与凭证管理最容易被忽视的深坑自动化流水线最忌讳把敏感信息硬编码在配置文件里。数据库密码、服务器 SSH 私钥、云厂商 SecretKey一旦写进仓库就等于把钥匙挂在了门口。正确做法是存在 CI/CD 工具的凭证管理模块里运行时通过变量引用。GitLab CI 有variables关键字还支持通过 Settings - CI/CD - Variables 配置项目级或组级变量使用的时候用$VARIABLE_NAME引用。Jenkins 提供credentials()方法Pipeline 里绑定 credentialId 就能拿到用户名密码或密钥文件。GitHub Actions 也有secrets对象。这些设计的目的只有一个让配置和代码分离同时保证敏感信息不出现在日志中。但要注意即便存在工具的凭证管理里也不是绝对安全。如果某个 Job 里直接执行echo $TOKEN那敏感信息照样会打进日志。所以日志脱敏也是一门必修课。你可以在流水线里配置禁止输出包含特定关键字的日志或者尽量用工具的封装好的登录方法比如docker login直接读取凭证而不是自己拼命令。环境变量的另一个坑是“作用域”。每个 Stage 用的环境可能不同构建阶段要 Node 环境变量部署阶段要 Kubernetes 的 kubeconfig。如果你把这些都放在全局变量里到了新环境或新成员接手时很难理清哪个变量是哪个阶段用的。我习惯把变量分为三级全局变量所有阶段通用、Stage 变量仅当前阶段、Job 变量仅当前 Job 使用。这样配置虽然多几行但维护起来清爽很多。3. 实操过程从零搭建一套可用的自动化流水线3.1 准备环境一台 Linux 服务器和 Docker我默认你已经有一台服务器操作系统是 Ubuntu 或 CentOS。如果还没有用虚拟机也一样最好内存不少于 4G。接下来所有操作我以 Ubuntu 为例命令几乎都能直接复制执行。第一步安装 Docker。Docker 不只是用来跑容器我们的 CI Runner 也建议用 Docker 方式安装这样 Jenkins 或 GitLab Runner 本身就是容器主机环境保持干净。安装命令如下sudo apt update sudo apt install -y apt-transport-https ca-certificates curl software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo add-apt-repository deb [archamd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io装完之后把当前用户加入 docker 组避免每次敲sudo dockersudo usermod -aG docker $USER newgrp docker第二步安装 GitLab Runner。如果你选择 GitLab CI需要在 GitLab 的管理界面获取注册 token然后跑这条命令注册 Runnersudo apt install -y gitlab-runner sudo gitlab-runner register \ --non-interactive \ --url https://gitlab.com/ \ --registration-token YOUR_TOKEN \ --executor docker \ --docker-image alpine:latest \ --description docker-runner注册完成后检查状态sudo gitlab-runner status如果一切正常你就能在 GitLab 的 Runner 列表里看到这个 Runner 处于“在线”状态。注意这里的--executor docker表示每次跑 Job 都会在一个全新 Docker 容器里执行环境隔离得很干净。很多新人踩过坑不用这个选项直接用 shell 执行器结果工作机上缺依赖Job 跑一次失败一次。3.2 用 Java/Node/Python 项目跑通第一个流水线接下来我以一个简单的 Python 项目为例演示一套包括“依赖安装、单元测试、接口测试、构建镜像、部署”的完整流水线。项目结构大概长这样my-python-app/ ├── .gitlab-ci.yml ├── app.py ├── requirements.txt └── tests/ ├── __init__.py └── test_api.py.gitlab-ci.yml内容如下stages: - install - test - build - deploy variables: APP_NAME: my-python-app IMAGE_TAG: $CI_COMMIT_SHORT_SHA install-job: stage: install image: python:3.11 script: - pip install -r requirements.txt test-job: stage: test image: python:3.11 script: - pip install -r requirements.txt - pytest tests/ -v --junitxmlreport.xml artifacts: when: always paths: - report.xml build-job: stage: build image: docker:24.0.7 services: - docker:24.0.7-dind script: - docker build -t $APP_NAME:$IMAGE_TAG . - docker save $APP_NAME:$IMAGE_TAG app.tar artifacts: paths: - app.tar deploy-job: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client script: - scp app.tar useryour-server:/opt/apps/ - ssh useryour-server docker load /opt/apps/app.tar docker stop $APP_NAME || true docker run -d --rm -p 8080:8080 --name $APP_NAME $APP_NAME:$IMAGE_TAG only: - main这段配置里有几个值得展开说明的点。install-job单独跑一次依赖安装看起来是和test-job重复安装了依赖实际上并不冲突。install阶段可以避免后面的测试阶段在每次调试依赖时都去重新解析依赖版本如果依赖安装失败流水线会第一时间告警而不是等测试阶段才报错。当然也有更高级的缓存依赖方案但首次搭建时简单直接更重要。测试阶段里的artifacts很关键。pytest生成的report.xml是 JUnit 格式的报告GitLab 可以在“测试”页签里图形化显示。加上when: always的意思是即使测试失败报告也要保留下来方便你查看失败用例的详情。构建阶段用了 Docker-in-Dockerdind因为我们要在 Runner 容器里再构建 Docker 镜像这需要挂载 Docker 服务。如果你觉得 dind 有点重也可以在 Runner 的配置里把/var/run/docker.sock挂载进容器直接用宿主机的 Docker 守护进程。两种方式各有优劣dind 隔离性更好但构建速度稍慢挂载 socket 速度更快但 Job 之间容易互相影响。部署阶段我写了only: main意思是只有 main 分支的提交才触发部署。这是非常重要的一条规则否则开发分支的每次 push 都会部署到生产环境出了事故可不好玩。实际项目中你还可以加上when: manual让部署变成手动点击才执行加一道人工确认。3.3 用 Webhook 实现自动触发如果你用的是 Jenkins而不是 GitLab CI那 Webhook 就是必须配的。GitLab 本身在你 push 代码时会发一个 POST 请求到 Jenkins 的接口Jenkins 收到请求后再触发构建。在 GitLab 项目里进入 Settings - Webhooks填写 Jenkins 的 Jenkins URL 加上/project/你的任务名这样的路径。GitLab 生成一个 Secret Token把同样的 Token 填到 Jenkins 的“触发远程构建”配置里这样能防止别人乱触发你的构建。等 Webhook 配置好你可以试一次本地git push到仓库观察 GitLab 的 Webhook 历史是否显示成功发送再看 Jenkins 是否开始构建。这整个链路其实不复杂但有一个很常见的坑Jenkins 服务器如果没有公网地址GitLab 服务器是没法主动请求到它的。这时你必须用内网穿透工具或者把 Jenkins 放在公司内网且保证网络可达。很多人在本地调试时怎么都触发不了就是因为这个网络原因。GitHub Actions 更简单项目中加.github/workflows/ci.yml文件push 之后 GitHub 服务器会自动发现并执行不需要自己配置 Webhook。这也是我为什么推荐个人项目用 GitHub Actions 的原因省事。3.4 接口自动化测试怎么融进流水线热词里“接口自动化”出现频率很高。接口自动化跑在 CI 里的价值在于每次代码变更都能快速知道后端接口有没有被破坏。但有个前提你要测试的服务必须先启动起来。在流水线中启动被测服务有多种方式我用得最多的是在test-job的before_script里启动应用test-job: stage: test image: python:3.11 before_script: - pip install -r requirements.txt - gunicorn app:app -b 0.0.0.0:5000 - sleep 3 script: - pytest tests/ -v这里的gunicorn是 Python 的 Web 服务器后台启动后等 3 秒再跑 pytest。接口测试用例里可以用requests或httpx去访问http://localhost:5000。不过要注意这种“后台启动应用”的方式在 Docker 容器里有个坑容器运行完before_script后主进程还在Job 结束时会残留一些进程。GitLab Runner 在执行完 Job 后会把整个容器销毁所以一般不会产生僵死进程。但如果你用的是 shell executor后台进程可能会残留建议在after_script里把服务停掉after_script: - pkill -f gunicorn || true如果你对接口自动化的数据管理有要求也可以在测试环境里预置数据库。每次跑测试之前清库、导 base data、跑接口、断言状态码和响应体然后清理数据。这些都可以用 pytest fixture 实现。在 CI 里环境越干净测试结果越可信。4. 常见问题与排查技巧实录4.1 流水线一直卡住不动流水线卡住最常出现在构建镜像阶段或者是安装依赖阶段。我遇到过好几次排查后发现要么是网络超时要么是 Docker 镜像拉取失败。如果是pip install卡住建议在配置里指定国内镜像源比如pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple如果是 Docker 镜像拉取卡住同样可以给 Docker 配置 registry mirror。我通常会在/etc/docker/daemon.json里加上镜像加速地址然后重启 Docker 服务。还有一个容易忽略的点Runner 的执行环境里没有配置代理或者 DNS 解析异常也会导致卡住。你可以先在本地手动跑一遍同样的命令排除环境因素再回到流水线里排查。4.2 阶段之间传递文件失败前面说过阶段之间的产物必须通过artifacts显式传递。新手经常遇到的问题是构建阶段生成的可执行文件到了部署阶段发现不存在。原因大概率是只写了artifacts: paths:但没有给deploy-job配置dependencies。默认情况下所有后续 Job 会下载前面所有 Job 的 artifacts但如果你明确指定了dependencies就要把需要产物来源的 Job 名称列全。在 GitLab CI 里如果你不想在某两个 Job 之间传递产物可以这样写deploy-job: ... dependencies: []这时部署阶段就不会下载构建阶段的 artifacts适合那种压根不需要产物的部署场景。不过大多数情况下部署是需要镜像包的所以要让deploy-job依赖build-jobdeploy-job: dependencies: - build-job4.3 部署流程里 SSH 认证失败部署阶段最典型的问题就是 SSH 连不上目标服务器。常见的原因有三个私钥路径不对、私钥权限不对、目标服务器没有把公钥加入 authorized_keys。在流水线里我一般把私钥内容放进 CI 的变量中运行时写入临时文件再用ssh -i指定私钥。注意私钥文件权限必须是 600否则 SSH 会拒绝使用。类似这样eval $(ssh-agent -s) echo $SSH_PRIVATE_KEY | tr -d \r | ssh-add - mkdir -p ~/.ssh chmod 700 ~/.ssh ssh-keyscan your-server ~/.ssh/known_hoststr -d \r是去掉 Windows 换行符很多人在 Windows 上复制私钥时会在末尾留下回车导致认证失败。这个细节非常坑我在本地调试时排查了很久才找到。如果你用的是内网服务器还要确认 Runner 能访问到目标服务器的 IP 和端口。在生产环境一般会限制只允许跳板机访问这时你需要在before_script里通过 ssh 隧道跳转。4.4 测试失败但流水线依旧继续这属于流程设计问题。默认情况下测试阶段的 Job 返回非零退出码流水线就会标记为失败并停止后续阶段。但如果你在script里写的是pytest || true那就人为掩盖了失败流水线会继续往下跑。这类写法是测试环节的大忌。我见过有人为了让流水线变绿把所有命令都加了|| true结果问题被掩盖直到线上才暴露。正确做法是只对“无害命令”加容错比如清理残留进程的pkill || true绝对不能对核心测试和构建命令加容错。如果你想让测试失败时不阻塞部署但又保留失败信号可以用allow_failure: trueGitLab CI 支持并在 Job 的期望和实际失败之间做权衡。但更好的方案仍然是测试没通过就别往下走。4.5 并发构建抢占资源当团队人变多流水线并发数上来很容易出现资源不足。如果你的 Runner 是单机 Docker executor默认并发数是 1后面的 Job 只能排队。你可以通过修改/etc/gitlab-runner/config.toml里的concurrent字段提高并发数但要先评估服务器 CPU 和内存。还有一种更合理的做法是给 Runner 加上limit参数限制每个 Runner 同时运行的 Job 数并用多个标签区分不同资源的 Runner。比如fast-runner跑前端构建heavy-runner跑后端集成测试。这样不同类型的任务不会互相抢占资源。4.6 热词之外AI 自动化测试、RPA 自动化是否该进 CI最近总看到“AI 自动化测试”“RPA 自动化电商”这些热词有人会问这些能不能也接入 CI/CD。我的观点是凡是能命令行执行的自动化任务理论上都能进流水线。比如用 Playwright 写的 UI 自动化测试可以装进 Docker 镜像在 CI 里跑npx playwright test生成 HTML 报告并通过 artifacts 归档。AI 写的测试脚本也一样只要他最终是“可执行文件返回码”就能成为流水线中的一个阶段。但要注意UI 自动化测试往往比接口测试脆弱很多非常依赖浏览器环境和等待时间。如果你把它放在部署前强制卡点经常会被又慢又脆的用例拖累整体效率。我的建议是先让 UI 自动化测试在夜间定时运行跑出稳定了再考虑成为 Merge Request 的强制检查项。自动化测试不是加得越多越好关键是要稳定、有维护价值。5. 实操心得避坑和经验总结最后这块我从个人项目出发分享几条比较接地气的经验希望能帮你少走弯路。第一CI/CD 的价值不是“部署速度变快”而是“失败代价变小”。以前手动部署上线前紧张兮兮现在流水线每次提交都自动走完整套流程哪一步挂了都能在 10 分钟内发现。心态上完全不一样。第二刚开始别追求复杂的工具箱。我见过有人第一次搭 CI/CD就把 Kubernetes、Argo CD、Prometheus 全堆上去结果半个月都跑不通。入门阶段就用最简单的 Jenkins 或 GitLab CI把构建、测试、部署三步跑通这就是骨架。后面需要了再在骨架上面长肉。第三流水线配置一定要带上版本控制。.gitlab-ci.yml或 Jenkinsfile 本身就是项目的一部分要提交进仓库。这样任何一次流水线改动都有历史记录能回滚能 review。很多人图方便在 Jenkins 网页上手动配置每一步确实能跑但你根本说不清上一次修改是什么时候改的、改了哪些内容。时间一长流水线就成了黑盒。第四多关注失败告警的渠道。流水线失败后第一时间通过邮件、钉钉、企业微信或 Slack 通知到相关人是自动化流程里不可缺少的一环。我之前分享过一个技巧在 GitLab CI 的after_script里根据 CI Job 的状态码调 webhook 发消息这样每次失败都能即时推送。热词里提到的“自动化运维”很大程度上也是从告警自动化开始的。第五没人维护的自动化不如没有自动化。CI/CD 不是一劳永逸的依赖更新、环境变化、需求变更都会让流水线失效。每周抽点时间检查一次构建时长和失败趋势该更新的更新该精简的精简这才是长期稳定运行的正道。按这个思路把第一条流水线搭出来你会发现后面再接触自动化测试、接口自动化、UI 自动化、容器化部署都会顺滑很多。因为底层逻辑都是一样的把重复的、确定性高的事情交给机器把人从重复劳动里解放出来去做更有创造性的事。这就是自动化 CI/CD 真正的价值所在。