在现代前端开发中，CI/CD（持续集成/持续部署）已成为保障代码质量和提升交付效率的必备工具。GitLab CI以其与代码仓库的深度集成和灵活的配置，成为了许多团队的首选。本文将分享一份面向前端项目的GitLab CI实践指南，覆盖核心概念和常见问题。

一、核心概念

在编写配置文件前，我们需要理解几个基本概念：

• Pipeline（流水线）：一次CI/CD任务的完整执行过程，可以由代码提交、合并请求等事件触发。
• Stages（阶段）：流水线由多个阶段组成，如 install -> build -> test。各阶段按顺序串行执行，前一阶段成功后才会进入下一阶段。
• Jobs（作业）：一个阶段可以包含多个并行的作业。例如，test 阶段可以同时运行 lint、unit-test 等多个作业。作业是执行任务的最小单元。
• Runner（执行器）：真正执行作业的载体。它通常是独立于GitLab服务器的机器，负责拉取代码、执行脚本并返回结果。

二、编写你的 .gitlab-ci.yml

所有的CI/CD规则都定义在项目根目录下的 .gitlab-ci.yml 文件中。

1. Job的拆分与合并

script 中的命令是串行的，而不同的 job 是并行的。是否应该将任务拆分为多个Job？

• 优点：拆分后可以并行执行，充分利用Runner资源，理论上能缩短总时长。
• 缺点：每个Job都需要初始化环境（拉取镜像、代码、缓存等），对于执行时间很短的脚本，这个固定开销反而会拖慢整体速度。

建议：对于没有强依赖关系且执行时间较长的任务（如单元测试和E2E测试），可以拆分为不同Job。对于 lint 这类快速任务，建议合并在一个Job中，使用 npm-run-all 等工具并行执行脚本。

2. 依赖管理、缓存与产物

这是前端CI配置中最核心的部分，主要涉及 node_modules 的处理。

• cache（缓存）：用于缓存项目依赖（如 node_modules），目的是加速后续任务。缓存不保证一定存在，即使缓存获取失败，Job也应能正常执行（只是会慢一些）。
• artifacts（产物）：用于在不同Stage之间传递文件（如 build 阶段生成的 dist 目录）。产物是Job的输出，后续Job可以依赖它。

最佳实践： 对于 node_modules，推荐同时使用 cache 和 artifacts。

• 在 install 阶段，使用 cache 加速 yarn install 或 npm install 的过程。
• 同时，将 node_modules 声明为 artifacts，以确保后续 build、test 等阶段一定能访问到完整的依赖。

install_deps:
  stage: install
  cache:
    key: ${CI_COMMIT_REF_SLUG}-node-modules
    paths:
      - node_modules/
  artifacts:
    paths:
      - node_modules/
    expire_in: 1 hour
  script:
    - yarn install --frozen-lockfile

3. 控制触发时机

很多时候我们不希望每次 commit 都触发整个CI流程，而是只在创建合并请求（Merge Request）时触发。这可以通过 rules (新版) 或 only/except (旧版) 关键字实现。

build_project:
  stage: build
  script:
    - yarn build
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

三、高级技巧与最佳实践

代码校验流程：本地 pre-commit hook 执行 lint-fix 自动修复，CI中的 lint Job只做检查，确保不合规代码无法合并。

显示代码覆盖率：在执行单元测试的Job中，通过 coverage 关键字和正则表达式，可以直接在GitLab界面上展示代码覆盖率。

在CI中修改代码？：强烈不建议。在CI Job中修改并提交代码，会再次触发CI，容易导致死循环。版本号等信息的修改应在发布流程中由脚本在本地完成。

掌握GitLab CI的配置，能极大地解放团队的生产力，是前端工程化体系中不可或缺的一环。