一文搞懂：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解决的是“不用人盯着，系统自动跑完整个交付流程”的问题。

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.yml：

name: 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/checkout@v4

# 2. 设置JDK
– name: Set up JDK 17
uses: actions/setup-java@v4
with:
java-version: '17'
distribution: 'temurin'

# 3. 缓存Maven依赖（加速构建）
– name: Cache Maven dependencies
uses: actions/cache@v3
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 -DskipTests=false

# 5. 上传JAR包作为构建产物（可选，便于下载查看）
– name: Upload JAR artifact
uses: actions/upload-artifact@v4
with:
name: app-jar
path: target/*.jar

# 6. 通过SCP上传JAR到服务器
– name: Deploy to server via SCP
uses: appleboy/scp-action@v0.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-action@v1.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 1

4.3 配置GitHub Secrets

工作流中使用了${{ secrets.XXX }}来保护敏感信息，需要在GitHub仓库的 Settings → Secrets and variables → Actions 中添加：

4.4 服务器端准备

服务器上需要提前准备好：

4.5 运行效果

配置完成后，每次git push到dev或main分支，GitHub Actions会自动触发：

整个过程全自动，无需任何人手工干预。

5️⃣ 流水线核心Stage详解

一条完整的CI/CD流水线通常包含以下阶段：

Stage 1: Checkout（拉取代码）

流水线的第一步，从代码仓库拉取最新代码。GitHub Actions的actions/checkout Action会自动完成。

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 零停机发布策略

7️⃣ 2026年CI/CD趋势：GitOps与ArgoCD

7.1 什么是GitOps？

GitOps是一种将Git作为唯一真实来源的运维模式。它把部署配置也写成代码，存放在Git仓库中，由自动化工具持续监控仓库变化并同步到生产环境。

核心思想：基础设施即代码 + 声明式配置 + 自动化同步。

7.2 ArgoCD：GitOps的Kubernetes引擎

ArgoCD是目前最流行的GitOps工具，专为Kubernetes设计。它持续监控Git仓库，自动将集群状态与声明的配置同步。

ArgoCD vs 传统CI/CD：

采用率：约三分之二的组织已在生产环境中运行ArgoCD。

7.3 CI/CD + GitOps 混合架构

2026年的典型实践是 CI负责构建，GitOps负责部署：

8️⃣ 总结与学习路线

8.1 核心要点速查

8.2 学习路线