别再手动部署了兄弟！聊聊我在项目中搞CICD的那些坑与经验-阿南达文事网

别再手动部署了兄弟！聊聊我在项目中搞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 + 手动部署的方式上线，那真的该思考下团队的交付效率了。

别再手动部署了兄弟！聊聊我在项目中搞CICD的那些坑与经验