19、持续集成/持续部署（CI/CD）与Git：GitHub Actions、GitLab CI 的基本配置与触发策略

聊到现代软件开发，有个词你肯定绕不开——CI/CD。说白了，就是让机器替你做那些重复、容易出错的事情。我刚开始带团队那会儿，大家还习惯手动合并、手动部署，每次上线都像在拆弹。后来引入了CI/CD，整个人都轻松了。

这一章，我们就来聊聊CI/CD和Git怎么配合。重点放在GitHub Actions和GitLab CI上，看看它们的基本配置和触发策略。

CI/CD 到底在解决什么问题？

先想一个问题：你写完代码，提交到Git仓库，然后呢？

传统做法是：同事拉下来，本地编译、跑测试、没问题再手动部署到服务器。这个过程慢、容易出错，而且特别依赖人的责任心。

CI/CD的思路是：你只管push代码，剩下的交给流水线。自动编译、自动测试、自动部署。如果哪一步挂了，流水线会立刻告诉你。

GitHub Actions 的基本配置

GitHub Actions 是 GitHub 自家的CI/CD工具。它的配置方式很直观——在仓库里放一个YAML文件就行。

我个人习惯把配置文件放在 .github/workflows/ 目录下。每个YAML文件就是一个工作流（Workflow）。

一个最简单的例子

假设你有一个Node.js项目，想在每次push时自动跑测试。可以这样写：

name: Node.js CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: 使用 Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'
    - run: npm ci
    - run: npm test

这个配置做了几件事：

• 监听 main 分支的 push 和 pull_request 事件
• 在 Ubuntu 最新环境上运行
• 拉取代码、安装依赖、跑测试

嗯，这里要注意：npm ci 比 npm install 更快更可靠，因为它严格依赖 package-lock.json。我在项目中遇到过好几次因为 npm install 意外升级了依赖版本导致测试失败的情况，后来就全面改用 npm ci 了。

触发策略：不只是 push

GitHub Actions 的触发方式很灵活。除了 push 和 pull_request，你还可以：

• 定时触发：用 schedule 事件，比如每天凌晨跑一次
• 手动触发：用 workflow_dispatch，可以在GitHub页面上点按钮运行
• 标签触发：打tag时自动构建并发布

举个例子，我想在打tag时自动发布到npm：

on:
  push:
    tags:
      - 'v*'

这样只要推送一个以 v 开头的标签，流水线就会触发。我曾经用这个策略配合语义化版本，实现了自动发布——每次打tag，流水线自动构建、测试、发布到npm，省了不少事。

GitLab CI 的基本配置

GitLab CI 的配置方式和 GitHub Actions 类似，也是用YAML文件。不过它放在项目根目录，文件名固定为 .gitlab-ci.yml。

一个简单的 GitLab CI 配置

stages:
  - test
  - build
  - deploy

test-job:
  stage: test
  script:
    - npm ci
    - npm test

build-job:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/

deploy-job:
  stage: deploy
  script:
    - scp -r dist/ user@server:/var/www/
  only:
    - main

这个配置定义了三个阶段：测试、构建、部署。每个阶段可以有一个或多个任务。注意 artifacts 关键字——它把构建产物传递给后续阶段。这个设计很巧妙，避免了重复构建。

触发策略：GitLab CI 的特色

GitLab CI 的触发策略和 GitHub Actions 大同小异，但有几个特色功能：

• Merge Request 触发：当MR被创建或更新时自动运行
• Pipeline 调度：类似 cron 定时任务
• 多项目流水线：一个项目的流水线可以触发另一个项目的流水线

我个人特别喜欢 GitLab 的 Merge Request 流水线。它会在MR页面直接显示测试结果，如果测试没通过，合并按钮是灰色的。这相当于在代码合入前加了一道自动门禁。

两种工具的对比

特性	GitHub Actions	GitLab CI
配置文件位置	.github/workflows/*.yml	.gitlab-ci.yml（根目录）
触发方式	push、PR、schedule、workflow_dispatch 等	push、MR、schedule、多项目触发等
运行环境	GitHub 托管的 runner 或自托管	GitLab 托管的 runner 或自托管
市场生态	丰富的 Actions 市场	模板和集成较多
免费额度	公开仓库免费，私有仓库有额度限制	自托管免费，SaaS版有额度限制

选哪个？说实话，看你的代码托管在哪。如果项目在GitHub上，就用Actions；在GitLab上，就用GitLab CI。没必要为了CI工具迁移代码仓库。

CI/CD 与 Git 的协作流程

最后，我想用一张图来展示CI/CD和Git是怎么配合的。这张图是我自己总结的，希望能帮你理清思路。

这张图展示了从开发者提交代码到最终部署的完整链路。注意那个虚线反馈箭头——如果流水线失败，开发者会立刻收到通知，可以马上修复。这就是CI/CD的核心价值：快速反馈。

好了，这一章的内容就到这里。CI/CD的配置其实不难，难的是设计出适合你团队的流水线。多试试，多调整，慢慢就会找到感觉。

---