先搞懂:CI/CD流水线的核心逻辑
不管用Jenkins还是GitLab CI,CI/CD的本质都是把“代码→构建→测试→部署”的手动流程拆成自动化步骤。比如:
– CI(持续集成):代码提交后自动拉取、构建、跑单元测试,快速发现编译或逻辑错误;
– CD(持续交付/部署):通过自动化把构建好的产物推到测试环境(交付)甚至生产环境(部署)。

记住一个公式:流水线 = 阶段(Stage)+ 步骤(Step)+ 触发器(Trigger)——触发器(比如代码提交、定时)触发流水线,每个阶段对应一个环节(如“拉取代码”“构建”),每个阶段里的步骤是具体操作(如git clone
、mvn package
)。
Jenkins篇:从安装到第一条流水线
1. 快速安装Jenkins(Docker版,亲测2025年最新稳定版)
Jenkins的传统安装容易踩“Java版本不兼容”的坑,用Docker最省心:
# 拉取最新LTS版镜像(JDK17)
docker pull jenkins/jenkins:lts-jdk17
# 启动容器(映射8080端口(Web界面)、50000端口(agent通信))
docker run -d --name jenkins -p 8080:8080 -p 50000:50000 -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-jdk17
启动后访问http://你的IP:8080
,用docker logs jenkins
找初始密码,完成安装。
2. 配置核心插件
Jenkins的威力在插件,必须装这几个:
– Git Plugin:拉取Git仓库代码;
– Pipeline:支持Jenkinsfile(声明式流水线,更易维护);
– Maven Integration(如果用Maven):构建Java项目;
– Blue Ocean(可选):更友好的流水线可视化界面。
安装方法:Jenkins首页→Manage Jenkins→Plugins→Available Plugins,搜索插件名勾选,点“Install without restart”。
3. 写第一条Jenkinsfile(声明式)
Jenkinsfile是流水线的“剧本”,放在项目根目录,例子:
pipeline {
agent any // 用任意可用的agent执行
triggers {
pollSCM('H/5 * * * *') // 每5分钟检查代码变更(也可以用Webhook触发,更高效)
}
stages {
stage('拉取代码') {
steps {
git branch: 'main', url: 'https://github.com/your-repo/your-project.git'
}
}
stage('构建') {
steps {
// 用Maven构建,依赖Maven Integration插件
withMaven(maven:'Maven 3.9.6') {
sh 'mvn clean package -DskipTests=false'
}
}
}
stage('单元测试') {
steps {
sh 'mvn test'
}
post {
// 测试失败发Slack通知(需安装Slack Notification Plugin)
failure {
slackSend channel: '#devops', message: "测试失败:${env.JOB_NAME} #${env.BUILD_NUMBER}"
}
}
}
stage('部署到测试环境') {
steps {
// 用scp推到测试服务器(需在Jenkins agent上配置免密登录)
sh 'scp target/your-app.jar test@test-server:/opt/apps/'
sh 'ssh test@test-server "systemctl restart your-app"'
}
}
}
}
保存后,在Jenkins里新建“Pipeline”项目,选择“从SCM获取Jenkinsfile”,填Git仓库地址,就能触发流水线了。
GitLab CI篇:用原生工具跑通自动化
GitLab CI是GitLab的原生CI/CD工具,不用额外装软件,和仓库深度集成,适合已经用GitLab做代码托管的团队。
1. 核心概念:.gitlab-ci.yml + Runners
- .gitlab-ci.yml:放在项目根目录,定义流水线的“剧本”;
- Runners:执行流水线任务的“ Worker”,可以是GitLab共享的,也可以自己部署(推荐私有runners,更可控)。
2. 写第一个.gitlab-ci.yml
例子(Java项目,用Maven构建):
# 定义流水线阶段(顺序执行)
stages:
- 拉取代码
- 构建
- 测试
- 部署测试环境
# 全局变量(所有job可用)
variables:
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository" # 缓存Maven依赖,加速构建
JAR_FILE: "target/your-app.jar"
# 拉取代码job
pull_code:
stage: 拉取代码
image: alpine/git:latest # 用轻量的Git镜像
script:
- git clone $CI_REPOSITORY_URL --branch $CI_COMMIT_BRANCH --depth 1 .
artifacts:
paths:
- ./* # 把代码作为产物传递给下一个job
# 构建job
build:
stage: 构建
image: maven:3.9.6-eclipse-temurin-17 # 带JDK17的Maven镜像
dependencies:
- pull_code # 依赖拉取代码的产物
script:
- mvn clean package -DskipTests=true
artifacts:
paths:
- $JAR_FILE # 保存构建好的jar包
# 测试job
test:
stage: 测试
image: maven:3.9.6-eclipse-temurin-17
dependencies:
- build
script:
- mvn test
# 缓存Maven依赖,下次构建不用重新下载
cache:
key: "$CI_COMMIT_REF_SLUG-maven"
paths:
- .m2/repository/
# 部署测试环境job
deploy_test:
stage: 部署测试环境
image: alpine:latest # 轻量Linux镜像,装ssh客户端
dependencies:
- build
script:
- apk add --no-cache openssh-client # 安装ssh
- ssh-keyscan test-server >> ~/.ssh/known_hosts # 信任测试服务器
- scp $JAR_FILE test@test-server:/opt/apps/ # 推送jar包
- ssh test@test-server "systemctl restart your-app" # 重启服务
only:
- main # 只在main分支触发
3. 注册私有Runners(关键!)
如果用GitLab共享runners,可能会遇到“资源不够”“速度慢”的问题,自己部署runners更稳:
1. 打开GitLab项目→Settings→CI/CD→Runners→Expand;
2. 复制“Registration token”;
3. 用Docker部署runners:
docker run -d --name gitlab-runner --restart always
-v /srv/gitlab-runner/config:/etc/gitlab-runner
-v /var/run/docker.sock:/var/run/docker.sock
gitlab/gitlab-runner:latest
4. 注册runners:
docker exec -it gitlab-runner gitlab-runner register
按照提示填:GitLab地址(如https://gitlab.com
)、token、描述(如“测试环境runners”)、标签(如“test-runner”)、 executor选docker
(用Docker执行job)。
避坑指南:两个工具的常见踩雷点
踩过的坑告诉你,少走弯路:
问题场景 | Jenkins解决方法 | GitLab CI解决方法 |
---|---|---|
插件版本冲突 | 用Docker安装Jenkins,固定插件版本(比如在Dockerfile里预装插件) | 不用插件!依赖GitLab原生功能 |
流水线卡住不执行 | 检查Jenkins的Executor数量(Manage Jenkins→Manage Nodes→Configure),增加executor | 检查runners状态(GitLab→CI/CD→Runners),看是否“在线” |
构建速度慢 | 用Pipeline的agent { docker { image 'xxx' } } ,用Docker镜像隔离环境 |
配置cache (如上面的Maven缓存),减少重复下载 |
权限问题(比如拉取代码失败) | 给Jenkins用户加Git仓库的SSH密钥(Jenkins→Credentials→添加SSH密钥) | 给runners配置GitLab的Deploy Token(项目→Settings→Repository→Deploy Tokens) |
进阶技巧:让流水线更稳定高效
- 参数化构建:让流水线更灵活。比如Jenkins可以加“分支选择”参数,GitLab CI可以用
variables
加自定义参数: - Jenkins:在项目配置→General→勾选“参数化构建过程”,加“Git参数”(Branch或Tag);
-
GitLab CI:在
.gitlab-ci.yml
里加variables
,比如:variables: DEPLOY_ENV: "test" # 默认部署测试环境
运行时可以在GitLab界面修改
DEPLOY_ENV
为prod
(生产环境)。 -
故障排查:快速定位问题。
- Jenkins:看“Console Output”(流水线页面→点击失败的stage→Console Output),找错误日志;
-
GitLab CI:看“Job Log”(CI/CD→Pipelines→点击失败的job→Log),GitLab会高亮错误行。
-
通知集成:让团队及时知道结果。
- Jenkins:装Slack、钉钉插件,在Pipeline里加
slackSend
或dingtalkNotify
; - GitLab CI:在项目→Settings→Integrations→加Slack或Email通知,当流水线失败时发消息。
最后想说:CI/CD不是“配置完就完事”,要定期优化——比如删除不用的插件(Jenkins)、清理旧的runners(GitLab CI)、调整缓存策略。关键是贴合团队的实际流程,不要为了“自动化”而自动化,能解决“手动操作麻烦”的问题才是好流水线。
原创文章,作者:,如若转载,请注明出处:https://zube.cn/archives/237