GitHub Actions 和 GitLab CI/CD

GitHub Actions

是什么？

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

核心组件：

1. Workflow：一个可配置的自动化过程，定义在仓库根目录的 .github/workflows/ 下的 YAML 文件中。一个仓库可以有多个 Workflow。

2. Event：触发 Workflow 运行的特定活动，例如 push、pull_request、issue_created 或按 schedule 运行。

3. Job：一个 Workflow 由一个或多个 Job 组成。每个 Job 在一个全新的虚拟环境中执行。

4. Step：一个 Job 由多个 Step 组成。Step 可以是一个 shell 命令，也可以是一个 Action。

5. Action：可重用的代码单元，是 GitHub Actions 生态系统的基石。你可以使用社区共享的 Action，也可以创建自己的。

怎么使用？

基本步骤：

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

2. 定义工作流：
   编辑这个 YAML 文件，指定何时触发以及要做什么。

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

# 文件位置： .github/workflows/ci.ymlname: 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 的 IDname: Build and Run Tests# 指定运行环境（GitHub 提供的虚拟机）runs-on: ubuntu-latest# 3. 定义 Stepssteps:# Step 1: 检出代码（使用社区 Action）- name: Checkout codeuses: actions/checkout@v4# Step 2: 设置 Node.js 环境- name: Setup Node.jsuses: actions/setup-node@v4with:node-version: '18' # 指定 Node.js 版本# Step 3: 安装依赖- name: Install dependenciesrun: npm ci# Step 4: 运行测试- name: Run testsrun: npm test# Step 5: 构建项目（如果需要）- name: Build projectrun: npm run build

1. 提交和推送：
   将创建好的 YAML 文件提交并推送到 GitHub 仓库。

2. 查看结果：
   在 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 的单一文件来完成的。

核心组件：

1. Pipeline：最高级别的组件，代表一次完整的构建、测试、部署过程。由 .gitlab-ci.yml 文件定义。

2. Stage：一个 Pipeline 由多个 Stage 组成（例如 build、test、deploy）。Stage 定义了任务的执行顺序。

3. Job：每个 Stage 包含一个或多个 Job。Job 是实际执行工作的最小单位（例如 run-unit-tests）。同一个 Stage 中的 Job 会并行执行。

4. Runner：一个轻量级、高可扩展的代理，它运行 Pipeline 中的 Job。Runner 可以安装在各种环境中，你需要为你项目注册并配置 Runner。

怎么使用？

基本步骤：

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

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

3. 定义 Pipeline：
   编辑 .gitlab-ci.yml 文件。

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

# 文件位置： .gitlab-ci.yml# 1. 定义 Stages（执行顺序）
stages:- install- test- build# 2. 定义 Jobs
install-dependencies:stage: installscript:- npm cionly: # 定义触发条件- main- develop- merge_requestsrun-tests:stage: testscript:- npm testonly:- main- develop- merge_requestsbuild-project:stage: buildscript:- npm run buildonly:- main- develop- merge_requestsartifacts: # 一个强大功能：将构建结果传递给后续的 Job/Pipelinepaths:- dist/ # 假设构建输出在 dist 目录

1. 提交和推送：
   将创建好的 YAML 文件提交并推送到 GitLab 仓库。

2. 查看结果：
   在 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 流程的企业。

• 从功能上讲：两者都非常强大，在绝大多数场景下都能实现相同的目标。选择通常取决于你选择的代码托管平台。