别再手动部署了兄弟！聊聊我在项目中搞CI/CD的那些坑与经验
别再手动部署了兄弟！聊聊我在项目中搞CI/CD的那些坑与经验
说实话，刚接触敏捷开发那会儿，我对 CI/CD（持续集成/持续交付）理解还停留在“每次开发提代码都要跑自动构建，然后神秘地上生产”这种模糊的印象。直到我亲手在一个敏捷项目中从0搭建完整的 CI/CD 流水线，才真切体会到这玩意儿到底有多香。
今天就和大家聊聊我在这个过程中踩过的坑、总结的经验和一些能落地的实践。讲真，如果你还在“测试环境手动部署”、“上线靠运维打包发包”、“回滚靠人肉备份”的原始阶段，那这篇文章可能对你帮助不小。
一、CI/CD 到底是个啥？为啥它和敏捷这么配？
很多人搞不清楚 CI/CD 到底是啥，搞个定义先：
- CI（持续集成）：开发人员频繁地把代码合并到主干，每次合并都会自动触发编译、单元测试等流程，确保代码质量；
- CD（持续交付/部署）：自动把构建好的应用部署到测试/预生产/生产环境，自动化到极致，手动几乎消失。
这跟敏捷开发强调的“小步快跑、快速迭代、频繁交付”简直是绝配。没有 CI/CD 的敏捷开发，和脱了链的自行车一样，说跑得快，其实满地是坑。
二、我项目里CI/CD的真实用法：从提代码到自动上线
我在的这个项目是个典型的 Spring Boot 后端 + Vue 前端 + MySQL + Redis 的电商系统。团队小但需求多，版本迭代快，一周两个 Sprint，产品经理需求像下饺子一样掉下来。
于是我搭了一套基于 GitLab + Jenkins + Docker + Kubernetes 的 CI/CD 流水线，结构如下：
代码语言：text复制开发 push -> GitLab webhook -> Jenkins 构建 + 测试 -> Docker 镜像构建推送 -> Kubernetes 滚动部署 -> Slack/DingTalk 通知下面我分步骤说说咋落地的。
三、CI：提交代码就能“自动干活”
先贴一个我在 Jenkinsfile 中设置的核心 CI 流程：
代码语言：groovy复制pipeline {
agent any
stages {
stage('Checkout') {
steps {
git branch: 'develop', url: '.git'
}
}
stage('Build') {
steps {
sh './mvnw clean package -DskipTests'
}
}
stage('Test') {
steps {
sh './mvnw test'
}
}
}
}说人话就是：
- 每次有人往 develop 分支提交代码，GitLab 自动触发 Jenkins；
- Jenkins 拉代码、打包、跑单测；
- 如果报错，Slack 上通知全组，谁写的谁修；
- 如果通过，就进入下一步：部署！
踩坑提醒：一定要把 mvn test 单独拆出 stage，否则构建失败原因不明确，调试难上加难。
四、CD：部署不是点按钮，而是“看戏”
CD 的核心目标就是：一行代码不写，一台服务器不登，就能部署上线。
我把 Jenkins 和 Kubernetes 联动起来，实现了一套“镜像构建 + 滚动发布”逻辑：
代码语言：groovy复制stage('Docker Build & Push') {
steps {
sh '''
docker build -t myapp:${BUILD_NUMBER} .
docker tag myapp:${BUILD_NUMBER} registry.example/myapp:${BUILD_NUMBER}
docker push registry.example/myapp:${BUILD_NUMBER}
'''
}
}
stage('K8s Deploy') {
steps {
sh '''
kubectl set image deployment/myapp myapp=registry.example/myapp:${BUILD_NUMBER} --record
'''
}
}部署完之后，我还搞了个“回滚机制”：
代码语言：bash复制kubectl rollout undo deployment/myapp有问题一键回滚，开发不怕试错，老板不怕翻车。
五、做CI/CD时我踩过的那些坑（用血泪换来的）
讲实话，CI/CD 不是搭个 Jenkins 装个插件就完事，以下这些坑，能让你少走点弯路：
1. 没有代码分支规范 = CI/CD 跑错方向
我们最后采用了标准的 Git Flow 模式：
master: 生产develop: 日常开发feature/*: 功能开发release/*: 预发布hotfix/*: 紧急修复
结合 GitLab 的权限控制 + merge request + Jenkins 多分支流水线，避免了“刚上线就炸”的事故。
2. 流水线一长就混乱 = stage分得不清晰
我后来将 CI/CD 流程抽象为以下 5 个阶段，每个阶段独立失败不会影响全局追踪：
阶段 | 内容 | 说明 |
|---|---|---|
Checkout | 拉代码 | 检查提交记录 |
Build | 编译打包 | 失败最多的地方 |
Test | 单元测试 | 保质量 |
Docker | 镜像构建 | 产出交付物 |
Deploy | Kubernetes发布 | 真正上线 |
3. 没有监控 = 上线等于盲投
上线不是 CI/CD 的结束，而是另一个监控流程的开始。我配置了 Prometheus + Grafana + Loki，实现以下告警：
- Pod Crash
- 请求量突变
- 响应时间超标
- 镜像拉取失败
真正做到：问题一出现，10秒内手机震动。
六、最后的唠叨：CI/CD不是省事，是省命
CI/CD 看似是一堆工具和流水线的组合，实则是一种团队文化。
它告诉我们：
代码不是写完就完了，只有部署了、运行了、被监控了，才算交付了价值。
如果你还在用 FTP + 手动部署的方式上线，那真的该思考下团队的交付效率了。