CI/CD 流水线

一、什么是 CI/CD

让机器代替人做"构建 + 测试 + 发布"：

push 代码 → 自动拉取 → 自动构建 → 自动测试 → 自动部署 → 通知结果

• CI（持续集成）：每次提交都自动构建 + 跑测试，问题早暴露。
• CD（持续交付/部署）：测试通过后自动发布到测试/生产环境。

好处：免人工出错、频率高、可回滚。测试不过就不允许上线，是质量红线。

二、主流方案

方案	特点
GitHub Actions	GitHub 内置，免费，本教程采用
GitLab CI	自建 GitLab 常用
Jenkins	老牌，环境多但维护重
云效/Jenkins X	阿里云等配套

三、GitHub Actions 基础

仓库根目录建 .github/workflows/deploy.yml：

name: Build and Deploy

# 触发条件：push 到 main 分支
on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: 拉取代码
        uses: actions/checkout@v4

      - name: 安装 Node
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: 构建前端（Vue）
        run: |
          cd web-vue
          npm ci
          npm run build

      - name: 安装 JDK 并构建后端
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17

      - name: 后端测试 + 打包
        run: |
          cd server
          mvn -B test
          mvn -B package -DskipTests

四、连接服务器自动部署

部署到自己的云服务器，需要在 GitHub 仓库配置 Secrets（加密存储）：

Settings → Secrets and variables → Actions → New repository secret

Secret	值
SERVER_HOST	服务器 IP
SERVER_USER	ssh 用户名
SERVER_SSH_KEY	私有密钥（PEM）

Secrets 加密存储，日志里只显示 ***，防止泄露。

然后加入部署步骤（用 rsync/scp + ssh 远程执行）：

      - name: 部署到服务器
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          source: "dist,server/target/*.jar"
          target: "/opt/mall/deploy"

      - name: 重启服务
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          script: |
            cd /opt/mall/deploy
            docker compose down && docker compose up -d --build

更优做法：构建 Docker 镜像推到镜像仓库（GitHub Container Registry / Docker Hub），服务器 docker compose pull 拉取运行。多实例部署时镜像方式更稳。

五、测试与环境分离（按分支/环境）

同一套流程可以映射到多环境（参考企业规范）：

# 按环境变量区分部署目标
env:
  ENV_FILE: server/src/main/resources/application-${{ inputs.env }}.yml

常用多环境拆分思路：

环境	触发	用途
测试 test	push dev 分支	联调/测试
预发 staging	push main 分支	上线前验证
生产 prod	打 tag v* 手动触发	正式发布

企业实践常有"预备环境"：和线上数据、配置一致，发布前最后验证，发现问题可回滚。

六、镜像仓库 + 服务器拉取（推荐进阶）

本地/CI 构建镜像 → push 到镜像仓库 → 服务器 pull → 更新容器

# CI 推送镜像
- name: 构建并推送后端镜像
  run: |
    docker build -t ghcr.io/你的账号/mall-server:latest ./server
    echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
    docker push ghcr.io/你的账号/mall-server:latest

服务器上：

docker pull ghcr.io/你的账号/mall-server:latest
docker compose up -d --no-deps server

加上版本号 tag，秒级回滚到上一个版本：

docker compose up -d --no-deps server
# 出问题就
docker compose up -d --no-deps --force-recreate server tag=v1.2.0

七、CI 质量门禁（必配）

在流水线里加上"红线上线禁止"的检查：

      - name: 代码质量
        run: |
          cd web-vue && npm run lint          # 前端 lint
          cd server && mvn -B test            # 后端测试（失败即中断）

• 后端：mvn test 失败 → 流程立刻中止，不部署。
• 前端：lint 不过 → 中止。
• 可选：SonarQube 代码质量平台（进阶）。

八、本章验收

• [ ] push 代码后 GitHub Actions 自动跑起来
• [ ] 测试/lint 失败时流水线变红并停止
• [ ] 成功后线上商城更新了
• [ ] 故意回滚一版（把 tag 指回去）能恢复

一句话

CI 保证质量，CD 保证速度。 把第 8 部分的测试和第 9 部分的部署接起来，就是完整的 DevOps 入门。