配合你写过的自动化部署脚本更进一步——像管理产品一样管理你的代码交付 写在前面在你的上一篇文章中我们已经写了一个Spring Boot应用的自动化部署脚本。通过scp上传JAR包、ssh远程执行命令实现了半自动化的发布流程。但这个过程还是需要人工介入你要在本地先打包然后手动执行脚本。如果团队有5个人每个人都在自己的电脑上打包版本可能不一致如果服务有10个一个个传包部署一次发布可能要花一个小时。CI/CD流水线要解决的正是这个问题——从“我手动触发一个脚本”升级为“代码一提交系统自动完成构建、测试、部署全流程”。今天我们把这套流程再往前推一步用GitHub Actions搭建一条完整的CI/CD流水线实现从代码push到生产部署的全自动化。1️⃣ CI/CD是什么——三个词搞懂核心概念CI/CD不是单一工具而是一套自动化软件交付方法论。把它拆开看就三件事CI持续集成代码一提交自动编译、跑单元测试、打包。CD持续交付/部署把打包好的产物自动部署到测试/生产环境。Pipeline流水线把上述步骤串成一条自动化生产线。把CI/CD理解为一条自动化生产线开发者提交代码相当于把原材料放上传送带接下来的编译、测试、打包、部署全部由机器自动完成人类只需要在关键节点做决策比如“是否发布到生产”。CI/CD的价值传统手工部署可能需要30分钟而自动化流水线可以在5分钟内完成。人工部署的错误率约为15%自动化部署可降至1%以下。以一个20人团队的中型项目为例采用CI/CD流水线后每日构建次数从5次提升到50次平均部署时间从45分钟缩短到8分钟。2️⃣ CI/CD vs 手动脚本本质区别在哪你写过的自动化部署脚本和CI/CD流水线区别在哪维度手动脚本CI/CD流水线触发方式人工手动执行代码push自动触发执行环境开发者本地电脑专用构建服务器/容器版本一致性每个人环境不同打包结果可能不一致统一构建环境每次结果可复现测试集成需要手动跑测试自动运行单元测试、集成测试多环境部署需要分别执行不同脚本一套配置自动部署到dev/test/prod回滚手动找旧版本重新部署一键回滚到任意历史版本可观测性全靠终端日志可视化面板每一步状态清晰可见一句话总结手动脚本解决的是“不用每次敲命令”的问题CI/CD解决的是“不用人盯着系统自动跑完整个交付流程”的问题。3️⃣ 主流CI/CD工具对比2026年CI/CD工具生态已经非常成熟主流选择有三Jenkins —— 老牌王者Pipeline as Code的先行者Jenkins是最流行的开源自动化服务器通过Pipeline as Code能力将构建、测试、部署流程代码化与应用代码一同存放在Git仓库中。优点插件生态最丰富几乎能对接任何系统自由度高适合复杂场景。缺点搭建和维护成本高界面老旧学习曲线陡峭。适合有专门DevOps团队的大型企业或需要高度定制化流水线的场景。GitLab CI —— 一体化平台开箱即用GitLab CI深度集成在GitLab中代码仓库和CI/CD在同一平台。优点无需额外搭建CI服务器配置简单一个.gitlab-ci.yml文件搞定一切。缺点必须使用GitLab作为代码仓库复杂场景下灵活性不如Jenkins。适合已经使用GitLab的团队追求开箱即用的体验。GitHub Actions —— 云原生时代的后起之秀GitHub原生的CI/CD工具与Git代码仓库深度集成。优点配置简单YAML文件与GitHub生态无缝集成免费额度充足Marketplace有大量现成Action可用。缺点重度依赖GitHub私有化部署需要GitHub Enterprise。适合使用GitHub的中小团队和个人开发者。选型建议个人项目或小团队 →GitHub Actions免费、简单、够用中型团队已用GitLab →GitLab CI大型企业复杂场景 →Jenkins。4️⃣ 实战Spring Boot GitHub Actions 完整流水线下面我们用GitHub Actions搭建一条完整的CI/CD流水线实现代码push → 自动构建 → 自动测试 → 自动部署。4.1 整体架构这个流程和你在上一篇文章中写的脚本逻辑一致只是触发方式从“手动执行”变成了“代码push自动触发”。4.2 创建GitHub Actions工作流在项目根目录创建.github/workflows/deploy.ymlname: CI/CD Pipeline # 触发条件push到dev或main分支 on: push: branches: [ dev, main ] # 环境变量 env: PROJECT_NAME: my-springboot-app SERVER_IP: ${{ secrets.SERVER_IP }} SERVER_USER: ${{ secrets.SERVER_USER }} DEPLOY_PATH: /opt/apps jobs: build-and-deploy: runs-on: ubuntu-latest steps: # 1. 拉取代码 - name: Checkout code uses: actions/checkoutv4 # 2. 设置JDK - name: Set up JDK 17 uses: actions/setup-javav4 with: java-version: 17 distribution: temurin # 3. 缓存Maven依赖加速构建 - name: Cache Maven dependencies uses: actions/cachev3 with: path: ~/.m2/repository key: ${{ runner.os }}-m2-${{ hashFiles(**/pom.xml) }} restore-keys: ${{ runner.os }}-m2 # 4. 编译、测试、打包 - name: Build with Maven run: mvn clean package -DskipTestsfalse # 5. 上传JAR包作为构建产物可选便于下载查看 - name: Upload JAR artifact uses: actions/upload-artifactv4 with: name: app-jar path: target/*.jar # 6. 通过SCP上传JAR到服务器 - name: Deploy to server via SCP uses: appleboy/scp-actionv0.1.7 with: host: ${{ secrets.SERVER_IP }} username: ${{ secrets.SERVER_USER }} key: ${{ secrets.SSH_PRIVATE_KEY }} source: target/*.jar target: ${{ env.DEPLOY_PATH }} strip_components: 1 # 7. SSH执行远程部署脚本 - name: Execute deploy script uses: appleboy/ssh-actionv1.0.3 with: host: ${{ secrets.SERVER_IP }} username: ${{ secrets.SERVER_USER }} key: ${{ secrets.SSH_PRIVATE_KEY }} script: | cd ${{ env.DEPLOY_PATH }} # 获取上传的JAR文件名 JAR_FILE$(ls -t *.jar | head -1) # 停止旧服务 sudo systemctl stop ${{ env.PROJECT_NAME }} || true # 备份旧JAR [ -f current.jar ] mv current.jar backups/current_$(date %Y%m%d%H%M%S).jar # 新JAR替换为current.jar mv $JAR_FILE current.jar # 启动新服务 sudo systemctl start ${{ env.PROJECT_NAME }} # 等待启动完成并检查健康状态 sleep 10 curl -f http://localhost:8080/actuator/health || exit 14.3 配置GitHub Secrets工作流中使用了${{ secrets.XXX }}来保护敏感信息需要在GitHub仓库的Settings → Secrets and variables → Actions中添加Secret名称说明SERVER_IP服务器IP地址SERVER_USERSSH登录用户名SSH_PRIVATE_KEYSSH私钥用于免密登录4.4 服务器端准备服务器上需要提前准备好systemd服务文件/etc/systemd/system/my-springboot-app.service定义服务的启动、停止、重启逻辑。部署目录/opt/apps包含backups/子目录用于存放历史版本。4.5 运行效果配置完成后每次git push到dev或main分支GitHub Actions会自动触发拉取最新代码编译打包利用Maven缓存加速运行单元测试上传JAR到服务器执行远程部署脚本完成服务重启整个过程全自动无需任何人手工干预。5️⃣ 流水线核心Stage详解一条完整的CI/CD流水线通常包含以下阶段Stage 1: Checkout拉取代码流水线的第一步从代码仓库拉取最新代码。GitHub Actions的actions/checkoutAction会自动完成。Stage 2: Build构建编译代码、运行单元测试、打包生成可部署的制品JAR包或Docker镜像。加速技巧使用依赖缓存避免每次重新下载Maven依赖。Stage 3: Test测试自动运行单元测试、集成测试确保代码质量。测试失败则流水线中断不会继续部署。Stage 4: Deploy部署将构建产物部署到目标环境。可以分多阶段部署到测试环境自动执行用于验证部署到生产环境通常需要人工确认通过input步骤等待批准Stage 5: Post后处理部署完成后的收尾工作清理工作空间、发送通知钉钉/邮件/ Slack等。6️⃣ 进阶实践多环境部署与质量门禁6.1 多环境部署实际项目中通常有开发、测试、生产多个环境。可以通过分支策略 环境变量实现差异化部署# .github/workflows/deploy.yml on: push: branches: [ dev, main ] jobs: deploy: runs-on: ubuntu-latest steps: # ... 构建步骤 ... - name: Deploy to Dev if: github.ref refs/heads/dev run: ./deploy-dev.sh - name: Deploy to Production if: github.ref refs/heads/main run: ./deploy-prod.sh # 生产部署可以增加人工确认步骤6.2 质量门禁Quality Gates在流水线中设置质量检查关卡不达标则不允许继续部署代码质量集成SonarQube进行代码扫描圈复杂度、代码重复率超标则失败测试覆盖率单元测试覆盖率低于阈值如80%则失败安全扫描依赖安全扫描OWASP发现高危漏洞则阻断性能基准API响应时间超过阈值则告警6.3 零停机发布策略策略原理适用场景滚动更新逐步替换旧实例新实例就绪后才终止旧实例大多数Web应用蓝绿部署新旧两套环境并存切换流量要求零风险的场景金丝雀发布先让少量用户使用新版本逐步放量需要灰度验证的场景7️⃣ 2026年CI/CD趋势GitOps与ArgoCD7.1 什么是GitOpsGitOps是一种将Git作为唯一真实来源的运维模式。它把部署配置也写成代码存放在Git仓库中由自动化工具持续监控仓库变化并同步到生产环境。核心思想基础设施即代码 声明式配置 自动化同步。7.2 ArgoCDGitOps的Kubernetes引擎ArgoCD是目前最流行的GitOps工具专为Kubernetes设计。它持续监控Git仓库自动将集群状态与声明的配置同步。ArgoCD vs 传统CI/CD维度传统CI/CDJenkins等GitOpsArgoCD部署方式Push模式CI工具主动推送Pull模式ArgoCD主动拉取配置漂移检测无自动检测并修正回滚重新部署旧版本Git revert即可回滚审计依赖CI日志Git提交历史即审计日志采用率约三分之二的组织已在生产环境中运行ArgoCD。7.3 CI/CD GitOps 混合架构2026年的典型实践是CI负责构建GitOps负责部署CI阶段GitHub Actions代码提交 → 构建 → 测试 → 生成Docker镜像 → 推送到镜像仓库 → 更新Git仓库中的部署配置YAMLCD阶段ArgoCD监控Git仓库 → 检测到配置变更 → 自动同步到Kubernetes集群8️⃣ 总结与学习路线8.1 核心要点速查概念一句话理解CI持续集成代码提交后自动编译、测试、打包CD持续交付/部署自动把制品部署到目标环境Pipeline流水线把CI/CD步骤串成自动化流程GitHub ActionsGitHub原生的CI/CD工具GitOps用Git管理部署配置自动同步ArgoCDKubernetes上的GitOps引擎8.2 学习路线阶段一理解CI/CD概念- 搞清楚CI和CD的区别理解流水线的价值阶段二搭建第一条流水线- 用GitHub Actions跑通从代码提交到服务器部署的全流程阶段三集成测试与质量门禁- 加入单元测试、代码扫描、测试覆盖率检查阶段四多环境与零停机部署- 实现dev/test/prod环境差异化部署学习蓝绿/金丝雀发布阶段五GitOps与ArgoCD- 将部署配置代码化用ArgoCD实现声明式部署
一文搞懂：CI/CD自动化流水线搭建——从代码提交到生产部署的全流程实战
配合你写过的自动化部署脚本更进一步——像管理产品一样管理你的代码交付 写在前面在你的上一篇文章中我们已经写了一个Spring Boot应用的自动化部署脚本。通过scp上传JAR包、ssh远程执行命令实现了半自动化的发布流程。但这个过程还是需要人工介入你要在本地先打包然后手动执行脚本。如果团队有5个人每个人都在自己的电脑上打包版本可能不一致如果服务有10个一个个传包部署一次发布可能要花一个小时。CI/CD流水线要解决的正是这个问题——从“我手动触发一个脚本”升级为“代码一提交系统自动完成构建、测试、部署全流程”。今天我们把这套流程再往前推一步用GitHub Actions搭建一条完整的CI/CD流水线实现从代码push到生产部署的全自动化。1️⃣ CI/CD是什么——三个词搞懂核心概念CI/CD不是单一工具而是一套自动化软件交付方法论。把它拆开看就三件事CI持续集成代码一提交自动编译、跑单元测试、打包。CD持续交付/部署把打包好的产物自动部署到测试/生产环境。Pipeline流水线把上述步骤串成一条自动化生产线。把CI/CD理解为一条自动化生产线开发者提交代码相当于把原材料放上传送带接下来的编译、测试、打包、部署全部由机器自动完成人类只需要在关键节点做决策比如“是否发布到生产”。CI/CD的价值传统手工部署可能需要30分钟而自动化流水线可以在5分钟内完成。人工部署的错误率约为15%自动化部署可降至1%以下。以一个20人团队的中型项目为例采用CI/CD流水线后每日构建次数从5次提升到50次平均部署时间从45分钟缩短到8分钟。2️⃣ CI/CD vs 手动脚本本质区别在哪你写过的自动化部署脚本和CI/CD流水线区别在哪维度手动脚本CI/CD流水线触发方式人工手动执行代码push自动触发执行环境开发者本地电脑专用构建服务器/容器版本一致性每个人环境不同打包结果可能不一致统一构建环境每次结果可复现测试集成需要手动跑测试自动运行单元测试、集成测试多环境部署需要分别执行不同脚本一套配置自动部署到dev/test/prod回滚手动找旧版本重新部署一键回滚到任意历史版本可观测性全靠终端日志可视化面板每一步状态清晰可见一句话总结手动脚本解决的是“不用每次敲命令”的问题CI/CD解决的是“不用人盯着系统自动跑完整个交付流程”的问题。3️⃣ 主流CI/CD工具对比2026年CI/CD工具生态已经非常成熟主流选择有三Jenkins —— 老牌王者Pipeline as Code的先行者Jenkins是最流行的开源自动化服务器通过Pipeline as Code能力将构建、测试、部署流程代码化与应用代码一同存放在Git仓库中。优点插件生态最丰富几乎能对接任何系统自由度高适合复杂场景。缺点搭建和维护成本高界面老旧学习曲线陡峭。适合有专门DevOps团队的大型企业或需要高度定制化流水线的场景。GitLab CI —— 一体化平台开箱即用GitLab CI深度集成在GitLab中代码仓库和CI/CD在同一平台。优点无需额外搭建CI服务器配置简单一个.gitlab-ci.yml文件搞定一切。缺点必须使用GitLab作为代码仓库复杂场景下灵活性不如Jenkins。适合已经使用GitLab的团队追求开箱即用的体验。GitHub Actions —— 云原生时代的后起之秀GitHub原生的CI/CD工具与Git代码仓库深度集成。优点配置简单YAML文件与GitHub生态无缝集成免费额度充足Marketplace有大量现成Action可用。缺点重度依赖GitHub私有化部署需要GitHub Enterprise。适合使用GitHub的中小团队和个人开发者。选型建议个人项目或小团队 →GitHub Actions免费、简单、够用中型团队已用GitLab →GitLab CI大型企业复杂场景 →Jenkins。4️⃣ 实战Spring Boot GitHub Actions 完整流水线下面我们用GitHub Actions搭建一条完整的CI/CD流水线实现代码push → 自动构建 → 自动测试 → 自动部署。4.1 整体架构这个流程和你在上一篇文章中写的脚本逻辑一致只是触发方式从“手动执行”变成了“代码push自动触发”。4.2 创建GitHub Actions工作流在项目根目录创建.github/workflows/deploy.ymlname: CI/CD Pipeline # 触发条件push到dev或main分支 on: push: branches: [ dev, main ] # 环境变量 env: PROJECT_NAME: my-springboot-app SERVER_IP: ${{ secrets.SERVER_IP }} SERVER_USER: ${{ secrets.SERVER_USER }} DEPLOY_PATH: /opt/apps jobs: build-and-deploy: runs-on: ubuntu-latest steps: # 1. 拉取代码 - name: Checkout code uses: actions/checkoutv4 # 2. 设置JDK - name: Set up JDK 17 uses: actions/setup-javav4 with: java-version: 17 distribution: temurin # 3. 缓存Maven依赖加速构建 - name: Cache Maven dependencies uses: actions/cachev3 with: path: ~/.m2/repository key: ${{ runner.os }}-m2-${{ hashFiles(**/pom.xml) }} restore-keys: ${{ runner.os }}-m2 # 4. 编译、测试、打包 - name: Build with Maven run: mvn clean package -DskipTestsfalse # 5. 上传JAR包作为构建产物可选便于下载查看 - name: Upload JAR artifact uses: actions/upload-artifactv4 with: name: app-jar path: target/*.jar # 6. 通过SCP上传JAR到服务器 - name: Deploy to server via SCP uses: appleboy/scp-actionv0.1.7 with: host: ${{ secrets.SERVER_IP }} username: ${{ secrets.SERVER_USER }} key: ${{ secrets.SSH_PRIVATE_KEY }} source: target/*.jar target: ${{ env.DEPLOY_PATH }} strip_components: 1 # 7. SSH执行远程部署脚本 - name: Execute deploy script uses: appleboy/ssh-actionv1.0.3 with: host: ${{ secrets.SERVER_IP }} username: ${{ secrets.SERVER_USER }} key: ${{ secrets.SSH_PRIVATE_KEY }} script: | cd ${{ env.DEPLOY_PATH }} # 获取上传的JAR文件名 JAR_FILE$(ls -t *.jar | head -1) # 停止旧服务 sudo systemctl stop ${{ env.PROJECT_NAME }} || true # 备份旧JAR [ -f current.jar ] mv current.jar backups/current_$(date %Y%m%d%H%M%S).jar # 新JAR替换为current.jar mv $JAR_FILE current.jar # 启动新服务 sudo systemctl start ${{ env.PROJECT_NAME }} # 等待启动完成并检查健康状态 sleep 10 curl -f http://localhost:8080/actuator/health || exit 14.3 配置GitHub Secrets工作流中使用了${{ secrets.XXX }}来保护敏感信息需要在GitHub仓库的Settings → Secrets and variables → Actions中添加Secret名称说明SERVER_IP服务器IP地址SERVER_USERSSH登录用户名SSH_PRIVATE_KEYSSH私钥用于免密登录4.4 服务器端准备服务器上需要提前准备好systemd服务文件/etc/systemd/system/my-springboot-app.service定义服务的启动、停止、重启逻辑。部署目录/opt/apps包含backups/子目录用于存放历史版本。4.5 运行效果配置完成后每次git push到dev或main分支GitHub Actions会自动触发拉取最新代码编译打包利用Maven缓存加速运行单元测试上传JAR到服务器执行远程部署脚本完成服务重启整个过程全自动无需任何人手工干预。5️⃣ 流水线核心Stage详解一条完整的CI/CD流水线通常包含以下阶段Stage 1: Checkout拉取代码流水线的第一步从代码仓库拉取最新代码。GitHub Actions的actions/checkoutAction会自动完成。Stage 2: Build构建编译代码、运行单元测试、打包生成可部署的制品JAR包或Docker镜像。加速技巧使用依赖缓存避免每次重新下载Maven依赖。Stage 3: Test测试自动运行单元测试、集成测试确保代码质量。测试失败则流水线中断不会继续部署。Stage 4: Deploy部署将构建产物部署到目标环境。可以分多阶段部署到测试环境自动执行用于验证部署到生产环境通常需要人工确认通过input步骤等待批准Stage 5: Post后处理部署完成后的收尾工作清理工作空间、发送通知钉钉/邮件/ Slack等。6️⃣ 进阶实践多环境部署与质量门禁6.1 多环境部署实际项目中通常有开发、测试、生产多个环境。可以通过分支策略 环境变量实现差异化部署# .github/workflows/deploy.yml on: push: branches: [ dev, main ] jobs: deploy: runs-on: ubuntu-latest steps: # ... 构建步骤 ... - name: Deploy to Dev if: github.ref refs/heads/dev run: ./deploy-dev.sh - name: Deploy to Production if: github.ref refs/heads/main run: ./deploy-prod.sh # 生产部署可以增加人工确认步骤6.2 质量门禁Quality Gates在流水线中设置质量检查关卡不达标则不允许继续部署代码质量集成SonarQube进行代码扫描圈复杂度、代码重复率超标则失败测试覆盖率单元测试覆盖率低于阈值如80%则失败安全扫描依赖安全扫描OWASP发现高危漏洞则阻断性能基准API响应时间超过阈值则告警6.3 零停机发布策略策略原理适用场景滚动更新逐步替换旧实例新实例就绪后才终止旧实例大多数Web应用蓝绿部署新旧两套环境并存切换流量要求零风险的场景金丝雀发布先让少量用户使用新版本逐步放量需要灰度验证的场景7️⃣ 2026年CI/CD趋势GitOps与ArgoCD7.1 什么是GitOpsGitOps是一种将Git作为唯一真实来源的运维模式。它把部署配置也写成代码存放在Git仓库中由自动化工具持续监控仓库变化并同步到生产环境。核心思想基础设施即代码 声明式配置 自动化同步。7.2 ArgoCDGitOps的Kubernetes引擎ArgoCD是目前最流行的GitOps工具专为Kubernetes设计。它持续监控Git仓库自动将集群状态与声明的配置同步。ArgoCD vs 传统CI/CD维度传统CI/CDJenkins等GitOpsArgoCD部署方式Push模式CI工具主动推送Pull模式ArgoCD主动拉取配置漂移检测无自动检测并修正回滚重新部署旧版本Git revert即可回滚审计依赖CI日志Git提交历史即审计日志采用率约三分之二的组织已在生产环境中运行ArgoCD。7.3 CI/CD GitOps 混合架构2026年的典型实践是CI负责构建GitOps负责部署CI阶段GitHub Actions代码提交 → 构建 → 测试 → 生成Docker镜像 → 推送到镜像仓库 → 更新Git仓库中的部署配置YAMLCD阶段ArgoCD监控Git仓库 → 检测到配置变更 → 自动同步到Kubernetes集群8️⃣ 总结与学习路线8.1 核心要点速查概念一句话理解CI持续集成代码提交后自动编译、测试、打包CD持续交付/部署自动把制品部署到目标环境Pipeline流水线把CI/CD步骤串成自动化流程GitHub ActionsGitHub原生的CI/CD工具GitOps用Git管理部署配置自动同步ArgoCDKubernetes上的GitOps引擎8.2 学习路线阶段一理解CI/CD概念- 搞清楚CI和CD的区别理解流水线的价值阶段二搭建第一条流水线- 用GitHub Actions跑通从代码提交到服务器部署的全流程阶段三集成测试与质量门禁- 加入单元测试、代码扫描、测试覆盖率检查阶段四多环境与零停机部署- 实现dev/test/prod环境差异化部署学习蓝绿/金丝雀发布阶段五GitOps与ArgoCD- 将部署配置代码化用ArgoCD实现声明式部署
