GitHub Actions 和 GitLab CI/CD

GitHub Actions

是什么？

GitHub Actions 是 GitHub 平台原生集成的自动化工具。它允许你直接在 GitHub 仓库中创建、测试和部署代码。它的核心概念是事件驱动 ：当某个事件发生在你的仓库时（如 push、pull_request），你可以触发一系列的工作流程。

核心组件：

Workflow ：一个可配置的自动化过程，定义在仓库根目录的 .github/workflows/ 下的 YAML 文件中。一个仓库可以有多个 Workflow。
Event ：触发 Workflow 运行的特定活动，例如 push、pull_request、issue_created 或按 schedule 运行。
Job：一个 Workflow 由一个或多个 Job 组成。每个 Job 在一个全新的虚拟环境中执行。
Step ：一个 Job 由多个 Step 组成。Step 可以是一个 shell 命令，也可以是一个 Action。
Action：可重用的代码单元，是 GitHub Actions 生态系统的基石。你可以使用社区共享的 Action，也可以创建自己的。

怎么使用？

基本步骤：

在仓库中创建工作流文件 ：

在你的 GitHub 仓库根目录下创建 .github/workflows 目录，然后在该目录下创建一个 YAML 文件，例如 ci.yml。
定义工作流 ：

编辑这个 YAML 文件，指定何时触发以及要做什么。

一个简单的 Node.js 项目 CI 示例：

复制代码

# 文件位置： .github/workflows/ci.yml

name: Node.js CI # Workflow 的名称

# 1. 定义触发事件
on:
  push:
    branches: [ "main", "develop" ] # 当推送到 main 或 develop 分支时触发
  pull_request:
    branches: [ "main" ] # 当向 main 分支发起 PR 时也触发

# 2. 定义 Jobs
jobs:
  build-and-test: # Job 的 ID
    name: Build and Run Tests
    # 指定运行环境（GitHub 提供的虚拟机）
    runs-on: ubuntu-latest

    # 3. 定义 Steps
    steps:
      # Step 1: 检出代码（使用社区 Action）
      - name: Checkout code
        uses: actions/checkout@v4

      # Step 2: 设置 Node.js 环境
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18' # 指定 Node.js 版本

      # Step 3: 安装依赖
      - name: Install dependencies
        run: npm ci

      # Step 4: 运行测试
      - name: Run tests
        run: npm test

      # Step 5: 构建项目（如果需要）
      - name: Build project
        run: npm run build

提交和推送 ：

将创建好的 YAML 文件提交并推送到 GitHub 仓库。
查看结果 ：

在 GitHub 仓库的 "Actions" 标签页中，你可以看到工作流的运行状态、日志和结果。

适用场景

2.1 持续集成（CI）

自动运行测试套件，确保代码变更不会破坏现有功能。
例如：在每次 push 到 main 分支时运行单元测试。

2.2 持续交付/部署（CD）

自动化构建和部署代码到测试环境或生产环境。
例如：将代码部署到 Docker 容器或云服务（如 Azure、AWS）。

2.3 自动化任务

自动化代码质量检查（如 ESLint、SonarQube）。
自动更新依赖项（如通过 Dependabot）。
自动化文档生成（如生成 API 文档）。

2.4 事件驱动工作流

在 GitHub 事件触发时执行任务，例如：
创建 Issue 时自动添加标签。
合并 Pull Request 后通知团队。

GitLab CI/CD

是什么？

GitLab CI/CD 是 GitLab 平台原生集成的强大持续集成、交付和部署工具。它与 GitLab 的其他功能（如问题跟踪、代码仓库）深度集成。它的配置是通过项目根目录的一个名为 .gitlab-ci.yml 的单一文件来完成的。

核心组件：

Pipeline ：最高级别的组件，代表一次完整的构建、测试、部署过程。由 .gitlab-ci.yml 文件定义。
Stage ：一个 Pipeline 由多个 Stage 组成（例如 build、test、deploy）。Stage 定义了任务的执行顺序。
Job ：每个 Stage 包含一个或多个 Job。Job 是实际执行工作的最小单位（例如 run-unit-tests）。同一个 Stage 中的 Job 会并行执行。
Runner：一个轻量级、高可扩展的代理，它运行 Pipeline 中的 Job。Runner 可以安装在各种环境中，你需要为你项目注册并配置 Runner。

怎么使用？

基本步骤：

在仓库中创建配置文件 ：

在你的 GitLab 仓库根目录下创建一个名为 .gitlab-ci.yml 的文件。
配置 Runner ：

你需要确保有一个活跃的 GitLab Runner 来执行你的任务。GitLab 提供了共享的 Runner，你也可以设置自己的私有 Runner。
定义 Pipeline ：

编辑 .gitlab-ci.yml 文件。

一个简单的 Node.js 项目 CI 示例（与上面 GitHub Actions 功能对应）：

复制代码

# 文件位置： .gitlab-ci.yml

# 1. 定义 Stages（执行顺序）
stages:
  - install
  - test
  - build

# 2. 定义 Jobs
install-dependencies:
  stage: install
  script:
    - npm ci
  only: # 定义触发条件
    - main
    - develop
    - merge_requests

run-tests:
  stage: test
  script:
    - npm test
  only:
    - main
    - develop
    - merge_requests

build-project:
  stage: build
  script:
    - npm run build
  only:
    - main
    - develop
    - merge_requests
  artifacts: # 一个强大功能：将构建结果传递给后续的 Job/Pipeline
    paths:
      - dist/ # 假设构建输出在 dist 目录

提交和推送 ：

将创建好的 YAML 文件提交并推送到 GitLab 仓库。
查看结果 ：

在 GitLab 项目页面的侧边栏中，进入 CI/CD > Pipelines，即可查看 Pipeline 的运行状态和详情。

核心区别与总结

特性	GitHub Actions	GitLab CI/CD
生态系统	深度集成于 GitHub	深度集成于 GitLab
配置方式	一个仓库可以有多个 Workflow 文件 (在 `.github/workflows/` 下)	一个仓库通常只有一个 `.gitlab-ci.yml` 文件
核心概念	事件驱动 (`on:`)，强调由事件触发工作流	阶段驱动 (`stages:`)，强调构建、测试、部署的流水线
运行环境	使用 GitHub 托管的 Runner 或自托管 Runner	需要配置和注册 GitLab Runner（共享或私有）
关键优势	- 与 GitHub 生态无缝集成 - Actions 市场极其丰富 - 对开源项目非常友好	- 一体化平台，从规划到部署 - 环境管理和审查应用功能强大 - Auto DevOps 可以自动配置

如何选择？

如果你深度使用 GitHub：GitHub Actions 是自然且最佳的选择，它的集成度和社区生态都非常出色。
如果你深度使用 GitLab：GitLab CI/CD 提供了无缝的一体化体验，特别是对于需要严格环境控制和一体化 DevOps 流程的企业。
从功能上讲：两者都非常强大，在绝大多数场景下都能实现相同的目标。选择通常取决于你选择的代码托管平台。