CI/CD 实战：GitHub Actions 自动化部署 Spring Boot 项目全流程（附多环境配置）

摘要：在现代软件开发中，手动部署不仅效率低下，还极易因人为操作失误引发生产环境故障。本文将以 Spring Boot 项目为例，从零开始详细介绍如何设计和实现一个企业级的 CI/CD 流水线，涵盖工作流配置、多环境部署策略、安全性考虑、Docker 容器化及性能优化等关键环节，带你完整走一遍落地流程。

一、为什么要给 Spring Boot 配置 CI/CD 流水线？

在传统开发模式中，部署 Spring Boot 项目通常面临几个痛点：

1. 手动构建成本高：每次更新都要本地打包、上传服务器，效率极低。
2. 环境不一致：本地运行正常，上线后因 JDK 或依赖版本不同导致异常（“在我机器上是好的”）。
3. 可追踪性差：没有明确的版本与构建记录，出现问题难以回溯。
4. 运维复杂：缺乏自动化的测试与部署，容易引入人为失误。

CI/CD（持续集成/持续部署）的出现正是为了解决这些问题，它通过标准化流程和即时反馈机制，将构建、测试、打包、部署全自动化，把部署成功率从手工时代的 60% 提升至 98% 以上。

二、CI/CD 总体架构与核心概念

1. 总体流程

Spring Boot 的 CI/CD 一般包含以下几个步骤：

代码提交 → GitHub/GitLab 自动触发 CI → Maven 构建 & 单元测试 → 构建 Docker 镜像 → 上传到镜像仓库 → 部署 CD → 部署到服务器/Kubernetes 集群。

2. GitHub Actions 核心概念

要掌握 GitHub Actions，首先需理解以下核心概念：

• Workflow (工作流)：定义在.github/workflows目录下的 YAML 文件。
• Event (事件)：触发 Workflow 运行的活动，如push或pull_request。
• Runner (执行器)：执行 Workflow 的服务器，GitHub 提供免费的 Ubuntu、Windows 和 macOS Runner。
• Job (作业) & Step (步骤)：Job 由多个 Step 组成，按顺序执行。

三、环境准备与安全配置

1. 前提条件

• 已有一个托管在 GitHub 上的 Spring Boot 项目，包含有效的pom.xml。
• 准备目标部署环境：云服务器（需配置好 SSH 访问）或 Kubernetes 集群。

2. 配置 GitHub Secrets

为了保护敏感的凭据不被暴露在代码中，必须使用 GitHub Secrets 管理账号密码，禁止写死在配置文件中。进入仓库的Settings -> Secrets and variables -> Actions，添加以下常用 Secrets：

• SERVER_HOST：目标服务器 IP。
• SERVER_USER：SSH 登录用户名。
• SERVER_SSH_KEY：服务器 SSH 私钥（用于认证）。
• SERVER_PORT：SSH 端口，通常为 22。
• DOCKER_USERNAME/DOCKER_PASSWORD：镜像仓库凭据。

四、Maven 构建最佳实践

Spring Boot 默认使用 Maven 作为构建工具，要适配 CI/CD，需注意以下最佳实践：

1. 使用 Profile 区分环境

在pom.xml中定义不同环境：

<profiles> <profile> <id>dev</id> <properties> <activatedProperties>dev</activatedProperties> </properties> </profile> <profile> <id>prod</id> <properties> <activatedProperties>prod</activatedProperties> </properties> </profile> </profiles>

构建时通过-P参数区分环境：mvn clean package -Pprod -DskipTests。

2. 合理使用插件

• Spring Boot 插件：简化可执行 JAR 构建。
• Surefire & Failsafe 插件：保证单元测试与集成测试在流水线执行。

五、Docker 容器化最佳实践

1. Dockerfile 编写（多阶段构建）

推荐使用多阶段构建，避免镜像过大：

# 第一阶段：构建 FROM maven:3.9.6-eclipse-temurin-17 AS build WORKDIR /app COPY . . RUN mvn clean package -DskipTests # 第二阶段：运行 FROM eclipse-temurin:17-jre-alpine WORKDIR /app COPY --from=build /app/target/app.jar app.jar # 健康检查 HEALTHCHECK --interval=30s --timeout=3s \ CMD curl -f http://localhost:8080/actuator/health || exit 1 ENTRYPOINT ["java", "-jar", "app.jar"]

2. 镜像优化建议

• 使用eclipse-temurin:17-jre-alpine等轻量化基础镜像。
• 定义HEALTHCHECK健康检查，保证容器状态可控。
• 尽量让应用无状态化，便于弹性扩缩容。

六、实战：GitHub Actions 工作流配置（附多环境）

以下是一个完整的 CI/CD 工作流配置示例（.github/workflows/ci-cd.yml），包含了从构建、测试、Docker 镜像推送到多环境部署的完整逻辑。

name: CI/CD Pipeline for Spring Boot on: push: branches: [ "main", "develop" ] tags: [ 'v*' ] # 监听版本标签触发生产部署 pull_request: branches: [ "main" ] env: JAVA_VERSION: '17' DOCKER_REGISTRY: 'registry.cn-beijing.aliyuncs.com' # 以阿里云镜像仓库为例 IMAGE_NAME: 'myrepo/spring-boot-app' jobs: # 作业1：构建与测试 build-and-test: runs-on: ubuntu-latest steps: - name: Checkout Code uses: actions/checkout@v4 - name: Set up JDK uses: actions/setup-java@v4 with: java-version: ${{ env.JAVA_VERSION }} distribution: 'temurin' cache: 'maven' # 自动缓存 Maven 依赖加速构建 - name: Build with Maven and Run Tests run: mvn -B clean verify -Dspring.profiles.active=test # 作业2：构建并推送 Docker 镜像 build-image: needs: build-and-test runs-on: ubuntu-latest if: github.event_name == 'push' steps: - name: Checkout Code uses: actions/checkout@v4 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - name: Log in to Container Registry uses: docker/login-action@v3 with: registry: ${{ env.DOCKER_REGISTRY }} username: ${{ secrets.DOCKER_USERNAME }} password: ${{ secrets.DOCKER_PASSWORD }} - name: Build and Push Docker Image uses: docker/build-push-action@v5 with: context: . push: true tags: ${{ env.DOCKER_REGISTRY }}/${{ env.IMAGE_NAME }}:latest cache-from: type=gha cache-to: type=gha,mode=max # 作业3：部署到测试环境 (develop 分支触发) deploy-to-staging: needs: build-image runs-on: ubuntu-latest if: github.ref == 'refs/heads/develop' environment: staging # 使用 GitHub Environments 区分测试和生产部署 steps: - name: Deploy to Staging Server via SSH uses: appleboy/ssh-action@v0.1.10 with: host: ${{ secrets.STAGING_SERVER_IP }} username: ${{ secrets.SERVER_USER }} key: ${{ secrets.SERVER_SSH_KEY }} script: | docker pull ${{ env.DOCKER_REGISTRY }}/${{ env.IMAGE_NAME }}:latest docker stop myapp || true docker rm myapp || true docker run -d -p 8080:8080 --name myapp ${{ env.DOCKER_REGISTRY }}/${{ env.IMAGE_NAME }}:latest # 作业4：部署到生产环境 (Tag 触发) deploy-to-production: needs: build-image runs-on: ubuntu-latest if: startsWith(github.ref, 'refs/tags/v') environment: production steps: - name: Deploy to Production Kubernetes uses: azure/setup-kubectl@v3 with: version: 'latest' - name: Configure kubectl run: | mkdir -p $HOME/.kube echo "${{ secrets.KUBECONFIG }}" > $HOME/.kube/config chmod 600 $HOME/.kube/config - name: Deploy to K8s run: | kubectl set image deployment/myapp myapp=${{ env.DOCKER_REGISTRY }}/${{ env.IMAGE_NAME }}:latest kubectl rollout status deployment/myapp --timeout=300s

七、高级部署模式与优化

1. 部署策略

除了直接重启，生产环境常采用更安全的部署策略：

• 蓝绿部署：将新版本部署到待机环境，通过切换软链接或 Service 指向来实现流量切换，并配合健康检查，失败则回滚。
• 滚动更新：在 Kubernetes 中通过kubectl rollout status监控更新过程，确保平滑过渡。

2. 性能优化与成本控制

• 依赖缓存：使用actions/cache缓存 Maven 依赖和 Docker layers，可节省 70% 左右的构建时间。
• 按需触发：通过配置on: push: paths:，仅当代码目录发生变更时才触发流水线，避免不必要的构建。

3. 部署门禁

在团队协作中，可使用trstringer/manual-approval等 Action 为生产部署添加人工审批步骤，确保发布安全。

八、服务器端部署脚本（附自动回滚）

如果采用传统服务器部署，建议编写健壮的部署脚本。以下脚本支持原子切换、健康检查、失败自动回滚及版本保留，是生产级别的实践：

#!/usr/bin/env bash set -euo pipefail APP_NAME="myapp" RELEASES_DIR="/opt/${APP_NAME}/releases" CURRENT_JAR="/opt/${APP_NAME}/current.jar" SERVICE_NAME="${APP_NAME}" NEW_JAR="${RELEASES_DIR}/$1" # 保存当前版本以便回滚 PREVIOUS_TARGET="$(readlink -f "${CURRENT_JAR}" 2>/dev/null || echo "")" # 原子切换：软链接指向新版本 ln -sfn "${NEW_JAR}" "${CURRENT_JAR}" sudo /usr/bin/systemctl restart "${SERVICE_NAME}" sleep 8 # 健康检查 if sudo /usr/bin/systemctl is-active --quiet "${SERVICE_NAME}"; then echo "Deploy success: $1" # 只保留最近 5 个版本 ls -1t "${RELEASES_DIR}"/*.jar 2>/dev/null | tail -n +6 | xargs -r rm -f exit 0 fi # 部署失败，执行回滚 echo "Deploy failed, attempting rollback..." if [[ -n "${PREVIOUS_TARGET}" && -f "${PREVIOUS_TARGET}" ]]; then ln -sfn "${PREVIOUS_TARGET}" "${CURRENT_JAR}" sudo /usr/bin/systemctl restart "${SERVICE_NAME}" sleep 8 if sudo /usr/bin/systemctl is-active --quiet "${SERVICE_NAME}"; then echo "Rollback successful" exit 1 fi fi echo "Rollback unavailable or failed" exit 1

注：执行上述脚本中的sudo systemctl需要在服务器上为部署用户配置 NOPASSWD 免密权限。

九、总结与最佳实践

CI/CD 并不仅仅是自动化工具链，而是一种工程文化。对于 Spring Boot 项目，Maven + Docker + GitHub Actions 这一套组合几乎可以覆盖从构建到部署的全链路需求：

• Maven 构建：Profile 区分环境，测试自动化，插件使用合理。
• Docker 化：镜像分层优化，健康检查必配，尽量无状态化。
• GitHub Actions：构建、推送、部署全流程自动化，Secrets 保证安全。
• 运维思维：监控、日志、告警体系要同步规划，不能只停留在部署。

通过三个月的自动化部署实践，某团队将部署频率从每周 2 次提升到每天 15 次，而部署失败率反而从 12% 降至 1.5%。如果你还在手动打包上传，那么正是时候把 CI/CD 流水线纳入团队开发流程了。未来，你还可以进一步结合 Kubernetes、Helm、ArgoCD 等工具，打造真正的云原生 DevOps 流程。