Ruby 使用 GitLab CI：从基础配置到多阶段流水线

落日邮差

发布时间：2026-08-24| 57人浏览过

原创

前言

Ruby 项目只靠本地手动测试，往往很难兼顾提交验证速度和环境一致性；一旦进入多人协作，问题会更明显。把 GitLab CI 接入后，可以把依赖安装、RSpec 测试、构建乃至部署都放进同一条流水线中执行。本文从最小可用配置写起，再解释缓存提速和多阶段编排的用途，帮助你判断一套 Ruby CI 该先做什么、后补什么。

Ruby 项目一旦开始多人协作，只靠本地手动执行测试和构建，很快就会遇到反馈慢、环境不一致、问题难回溯这些常见麻烦。把 GitLab CI 接进项目后，可以把测试、构建甚至打包部署统一放进流水线里执行。下面就从最基础的配置文件写法讲起，再说明缓存和多阶段流程分别适合解决什么问题，帮助你判断一套 Ruby CI 流程该如何落地。

GitLab CI 能为 Ruby 项目解决什么问题

GitLab CI 是 GitLab 自带的持续集成服务，核心做法是在项目根目录放置一个 .gitlab-ci.yml 文件，用它描述流水线中的执行步骤。对于 Ruby 项目来说，这个文件通常会负责安装依赖、执行测试，以及根据需要补上构建或部署任务。

它的价值主要体现在几个方面：

自动化测试：每次提交后都能自动运行测试，减少漏测带来的风险。
快速反馈：开发者可以尽快知道某次提交是否破坏了已有功能。
版本可追溯：每次构建都绑定具体代码版本，定位问题更直接。
环境一致性：借助统一镜像或容器环境，尽量避免“我本地没问题”的情况。

如果你的 Ruby 应用已经在使用 Bundler、RSpec 这类常见工具，那么接入 GitLab CI 的门槛并不高，通常从一份最小配置开始就够用了。

如何编写最小可用的 `.gitlab-ci.yml`

开始接入时，先创建一个最基础的 .gitlab-ci.yml 文件。它至少要说明使用什么镜像、流水线包含哪些阶段，以及每个 job 具体执行什么命令。

展示 Ruby 项目最小 GitLab CI 配置组成的信息图 — **最小 Ruby CI 配置结构图**把镜像、阶段、依赖安装和测试构建 job 拆开看，更容易理解一份最小 Ruby CI。

示例配置

image: ruby:2.7

stages:
  - test
  - build

cache:
  paths:
    - vendor/bundle/

before_script:
  - gem install bundler
  - bundle install --path vendor/bundle

test:
  stage: test
  script:
    - bundle exec rspec

build:
  stage: build
  script:
    - echo "Building the application..."

这份配置表达的是一条很典型的 Ruby 流水线：

通过 image: ruby:2.7 指定运行环境。
使用 stages 定义两个阶段：test 和 build。
在 before_script 中先安装 Bundler，再执行 bundle install --path vendor/bundle。
test job 运行 bundle exec rspec，用于执行测试。
build job 则演示了如何追加一个构建步骤。

对很多项目来说，第一步不需要把流程设计得太复杂。只要先保证每次提交都能自动安装依赖并跑通测试，就已经能明显提升协作质量。后续再根据项目需要继续拆分任务，会比一开始堆很多阶段更容易维护。

为什么缓存能明显加快 Ruby 构建

Ruby 项目在 CI 中最常见的耗时点之一，就是重复安装 gem 依赖。如果每次流水线都从零开始下载和安装，执行时间会被明显拉长。GitLab CI 的缓存机制正是为这种场景准备的。

cache:
  paths:
    - vendor/bundle/

这里缓存的是 vendor/bundle/ 目录，也就是通过 Bundler 安装下来的依赖内容。这样配置后，GitLab CI 在后续构建时可以优先恢复这部分缓存，而不是每次重新安装所有 gem。

这项配置带来的直接收益有两点：

缩短流水线执行时间，尤其在依赖较多时更明显。
减少重复下载，提高 CI 资源利用率。

当然，缓存的作用是“加速”，不是替代依赖安装逻辑。也就是说，bundle install --path vendor/bundle 依然要保留，只是当缓存可用时，这一步会变得更快。

多阶段流水线适合哪些 Ruby 项目场景

当项目流程不再只有“跑测试”这么简单时，就可以考虑把流水线拆成多个阶段。GitLab CI 支持按顺序组织更复杂的工作流，例如先构建，再打包，最后部署。

展示 GitLab CI 缓存和多阶段依赖关系的信息图 — **缓存与多阶段流水线关系图**这张图把缓存恢复、构建产物传递和部署顺序放到同一张关系图里，便于理解 CI。

示例：多阶段构建流程

stages:
  - build
  - package
  - deploy

build_job:
  stage: build
  script:
    - echo "Building the application..."

package_job:
  stage: package
  dependencies:
    - build_job
  script:
    - echo "Packaging the application..."
  artifacts:
    paths:
      - package.tar.gz

deploy_job:
  stage: deploy
  dependencies:
    - package_job
  script:
    - echo "Deploying the application..."

这段配置展示了一个比基础示例更完整的执行顺序：