之前在github上发布releases，一直是自己手动编译，直到后来才知道CICD这玩意，持续集成持续交付持续部署

CI/CD，全称为 Continuous Integration, Continuous Delivery, and Continuous Deployment（持续集成、持续交付和持续部署），是提高软件开发效率、保障代码质量和加速产品上市的核心方法论。它定义了一套自动化、可靠的流程，确保代码从开发者的电脑到最终用户手中的过程是快速且顺畅的。

1.什么是CI/CD？

    CICD不是一个单一的工具，而是一系列操作的集合，它将软件的构建，测试，发布各个环节自动化

阶段一： CI - 持续集成 Continuous Integration

持续集成可以将开发者的代码合并到主分支，然后自动验证它的可用性，CI服务器，比如我们将要使用的Github Actions和大名鼎鼎的Jenkins，它们检测到代码的提交后，会自动开始编译代码，比如运行maven的一系列编译操作，并且运行单元测试和集成测试，验证代码的逻辑是否严密，确保代码没有破坏其他功能

阶段二：CD-持续交付与持续部署 Continuous Delivery/Deployment

CD是CI的一个眼神，会将代码发布到测试环境，虽然持续交付和持续部署的英语都是CD，但它们仍然有较大的区别

A.持续交付：

持续交付确保了代码可以被安全的、快速的发布到生产环境，但是需要手动触发

比如，当代码通过CI阶段后，会自动部署到测试环境或者预发布环境，等待工程师审核，发布到正式的生产环境

B.持续部署：

将代码变更从主分支到生产环境的整个过程完全自动化，自动部署到生产环境，不需要手动触发

2.CI/CD Pipeline 的工作流程

一个典型的CICD  Pipeline包括以下的核心步骤

3.CI/CD的重要性

优势一：加速发布周期

自动化流程减少了手动操作的时间，使原本可能需要几个小时或者很久的发布流程简化

优势二：提高代码质量和健壮性

集成测试和单元测试会检测代码的健壮性和可执行性，使得开发者可快速的发现新GIT中可能的BUG

优势三：降低发布风险

每次提交的变更小，出现问题易于定位

优势四：增强协作与透明度

团队可以更快的知道代码是否通过了测试，是否可以被安全部署

4.实战（以我的MC插件为例）

为了降低成本和简化操作，我使用了Github Actions作为我的CICD工作流

首先，在项目根目录下创建.github文件夹，并在里面创建一个工作流文件夹，我这里叫workdflows，在这个文件夹下创建一个ci.yml

编辑YAML文件

name: XiBackpack CI/CD Pipeline //工作流名称

on:
  push:
    # 仅在 'master' 分支推送时触发 CI/CD 流程，注意，一定要写对，否则无法执行工作流
    branches: [ master ]
  workflow_dispatch:
  # 允许手动从 GitHub Actions 页面触发此工作流

jobs:
  build_and_release:
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      # 步骤 1: 设置 Java 环境 (更改为 Java 8)
      - name: Set up JDK 8
        uses: actions/setup-java@v4
        with:
          java-version: '8'
          distribution: 'temurin'
          cache: maven

      # 步骤 2: 使用 Maven 构建项目
      - name: Build with Maven
        # clean install 会编译代码、运行测试并生成 JAR 文件到 target/ 目录
        run: mvn clean install -B

      # 步骤 3: 提取项目名称和版本号 (用于命名 Release 和 JAR)
      - name: Extract Project Info
        id: info
        run: |
          # 从 pom.xml 中获取项目版本号
          PROJECT_VERSION=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)
          echo "VERSION=$PROJECT_VERSION" >> $GITHUB_OUTPUT
          # 从 pom.xml 中获取项目名称 (或使用仓库名)
          PROJECT_NAME=${{ github.event.repository.name }}
          echo "NAME=$PROJECT_NAME" >> $GITHUB_OUTPUT

      # 步骤 4: 上传 JAR 文件作为构建产物 (CI 部分)
      - name: Upload JAR Artifact (CI)
        uses: actions/upload-artifact@v4
        with:
          # 上传生成的 JAR 文件 (例如: XiBackpack-1.0.0.jar)
          name: ${{ steps.info.outputs.NAME }}-v${{ steps.info.outputs.VERSION }}
          # 匹配 target 目录下以 .jar 结尾的文件
          path: target/*.jar
          retention-days: 7

      # 步骤 5: 创建 GitHub Release (CD 部分 - 仅在 master 分支推送时创建)
      - name: Create GitHub Release (CD)
        if: github.event_name == 'push' && github.ref == 'refs/heads/master'
        uses: softprops/action-gh-release@v2
        with:
          # 使用项目版本号作为 Tag (例如: v1.0.0)
          tag_name: v${{ steps.info.outputs.VERSION }}
          name: Release v${{ steps.info.outputs.VERSION }}
          body: |
            ### XiBackpack 新版本 ${{ steps.info.outputs.VERSION }}
            - 自动构建和发布。
            - 详情请查看 commit 历史记录。
          # 附带编译好的 JAR 文件到 Release
          files: target/*.jar
        env:
          # 必须设置 GITHUB_TOKEN，但 GitHub Actions 会自动处理，无需手动创建
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

保存文件，将其提交至github上 ，找到仓库，进入Github Actions

点击最新的提交

可以看到代码已经被成功构建成了一个工件