CI/CD 学习文档

核心要点（TL;DR）

CI/CD 将代码提交、构建、测试、部署、监控串联成自动化流水线，核心目标是快速且可靠地交付价值。
GitHub Actions、GitLab CI、Jenkins 各有适用场景，关键概念是 workflow/pipeline、job/stage、runner 与 artifact。
Docker 与多阶段构建保证环境一致性，蓝绿、金丝雀、滚动部署等策略可降低发布风险。
自动化测试必须作为质量门禁，发布流程必须具备回滚能力，监控告警应覆盖错误率、性能与业务指标。
CI/CD 成熟度从手动部署逐步演进到 DevOps 文化，安全左移（密钥管理、依赖扫描、镜像安全）不可或缺。

学习时长与前置知识

建议学习时长：2-3 周（每周投入 6-8 小时）
前置知识：Git、Linux 基础、构建工具

一、前言：从手工发布到自动化交付

想象你经营一家电商网站。每次上新功能，都需要经历以下步骤：

开发新功能
在本地测试
把代码上传到服务器
安装依赖
构建项目
重启服务
线上验证

如果每次都要手动执行这些步骤，不仅效率低下，还容易出错。上错文件、忘改配置、漏跑测试等问题会层出不穷。

CI/CD 就是要把这套流程自动化。它像是给软件交付装上了"流水线"：代码提交后自动测试、自动构建、自动部署，让发布变得像按下按钮一样简单可靠。

二、CI/CD 流程与价值

2.1 什么是 CI？

CI（Continuous Integration，持续集成）指的是开发人员频繁地将代码合并到主干分支，每次合并都自动触发构建和测试。

核心价值：

早发现早修复：集成问题在代码合并时就暴露，而不是等到发布前
减少分支冲突：频繁集成避免长时间的分支隔离
自动化验证：每次提交都有测试兜底

2.2 什么是 CD？

CD 有两个常见含义：

Continuous Delivery（持续交付）：代码通过测试后，随时可以部署到生产环境，但部署动作可能需要人工确认
Continuous Deployment（持续部署）：代码通过测试后，自动部署到生产环境

2.3 CI/CD 流水线

一条完整的 CI/CD 流水线通常包括：

代码提交 → 拉取代码 → 安装依赖 → 代码检查 → 单元测试 → 构建 → 镜像打包 → 部署 → 线上验证

生活化比喻：CI/CD 就像一条汽车生产线。每个工位只做一件事：焊接、喷漆、组装、检测。汽车（代码）自动流转，最后直接开下生产线（上线）。

三、GitHub Actions 基础配置

3.1 什么是 GitHub Actions？

GitHub Actions 是 GitHub 提供的 CI/CD 服务。它通过 YAML 文件定义工作流（Workflow），存放在 .github/workflows/ 目录下。

3.2 基础示例

yaml

# .github/workflows/ci.yml
name: CI

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

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

3.3 核心概念

Workflow（工作流）：一个 YAML 文件对应一个工作流
Job（任务）：工作流中的执行单元，多个 Job 可以并行
Step（步骤）：Job 中的具体命令
Action（动作）：可复用的步骤，如 actions/checkout
Runner（运行器）：执行 Job 的机器

四、GitLab CI 基础配置

4.1 什么是 GitLab CI？

GitLab CI 是 GitLab 内置的 CI/CD 工具。配置写在仓库根目录的 .gitlab-ci.yml 文件中。

4.2 基础示例

yaml

# .gitlab-ci.yml
stages:
  - install
  - test
  - build
  - deploy

install:
  stage: install
  script:
    - npm ci
  cache:
    paths:
      - node_modules/

test:
  stage: test
  script:
    - npm run lint
    - npm test

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

deploy:
  stage: deploy
  script:
    - echo "Deploy to production"
  only:
    - main

4.3 核心概念

Pipeline（流水线）：由多个 Stage 组成
Stage（阶段）：同一阶段的 Job 并行执行，不同阶段顺序执行
Job（任务）：具体执行单元
Runner（执行器）：运行 Job 的代理
Artifacts（产物）：Job 之间传递的文件

五、Jenkins 基础配置

5.1 什么是 Jenkins？

Jenkins 是开源的自动化服务器，历史悠久，生态丰富。它通过插件扩展能力，适合私有部署和复杂场景。

5.2 Jenkins Pipeline

Jenkins 支持声明式 Pipeline：

groovy

// Jenkinsfile
pipeline {
  agent any
  stages {
    stage('Install') {
      steps {
        sh 'npm ci'
      }
    }
    stage('Test') {
      steps {
        sh 'npm run lint'
        sh 'npm test'
      }
    }
    stage('Build') {
      steps {
        sh 'npm run build'
      }
    }
    stage('Deploy') {
      steps {
        sh 'scp -r dist user@server:/var/www/app'
      }
    }
  }
}

5.3 三者对比

工具	托管方式	配置语言	生态	适用场景
GitHub Actions	SaaS/Self-hosted	YAML	丰富	GitHub 项目
GitLab CI	内置/Self-managed	YAML	丰富	GitLab 项目
Jenkins	Self-hosted	Groovy	极丰富	私有部署、复杂流程

六、Docker 基础与镜像构建

6.1 什么是 Docker？

Docker 是一种容器化技术。它把应用及其运行环境打包成一个"镜像"，确保无论在谁的机器上运行，结果都一致。

生活化比喻：传统的部署像是把菜谱（代码）交给不同厨师（服务器），每个人做出来的味道可能不一样；Docker 则是预制菜，密封包装，任何地方加热（运行）都是同样的味道。

6.2 Dockerfile 示例

dockerfile

# Dockerfile
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["node", "server.js"]

6.3 常用命令

bash

docker build -t myapp:1.0 .
docker run -p 3000:3000 myapp:1.0
docker push registry.example.com/myapp:1.0

6.4 多阶段构建

多阶段构建可以减小最终镜像体积：

dockerfile

# 构建阶段
FROM node:20-alpine AS builder
WORKDIR /app
COPY . .
RUN npm ci && npm run build

# 运行阶段
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

七、部署流水线

7.1 常见部署策略

蓝绿部署：同时准备两套环境（蓝环境和绿环境），一套对外服务，另一套部署新版本。验证通过后切换流量。

金丝雀发布：先让一小部分用户访问新版本，观察没有问题后再逐步扩大流量。

滚动部署：逐个替换旧实例为新实例，不需要额外资源，但回滚较慢。

7.2 自动化发布流程

代码合并 → 构建镜像 → 推送镜像仓库 → 更新 K8s 部署 → 健康检查 → 完成发布

八、自动化测试与回滚策略

8.1 自动化测试分层

单元测试：测试最小功能单元，快速、独立
集成测试：测试模块之间的协作
E2E 测试：模拟真实用户操作

8.2 CI 中的测试

测试应该在 CI 中自动执行，并且设置质量门禁：

yaml

- run: npm run test:unit
- run: npm run test:e2e
- run: npm run test:coverage

8.3 回滚策略

没有 100% 安全的发布。回滚策略包括：

代码回滚：回退到上一个稳定版本
镜像回滚：重新部署上一个版本的镜像
数据库回滚：谨慎处理，通常需要向前兼容的迁移脚本
流量回滚：通过蓝绿/金丝雀快速切回旧版本

九、常见误区与最佳实践

误区一：CI/CD 就是自动化部署

CI/CD 不只是部署，还包括代码检查、测试、构建、监控等全链路自动化。

误区二：测试放到上线后再补

没有自动化测试的 CI/CD 是裸奔。必须在流水线中加入测试门禁。

误区三：一次发布所有变更

大版本发布风险高。应采用小步快跑、金丝雀发布、特性开关等方式降低风险。

最佳实践

所有代码提交都触发 CI
主分支必须时刻保持可部署状态
使用 Docker 保证环境一致性
测试失败立即修复，禁止绕过测试
发布流程必须可回滚
监控线上指标，建立告警机制

十、总结

CI/CD 是现代软件工程的核心实践。它把开发、测试、部署串联起来，形成高效可靠的交付流水线。掌握 GitHub Actions、GitLab CI、Jenkins 的配置方法，理解 Docker 容器化、部署策略和回滚机制，是每个前端工程师进阶的必备技能。

十一、CI/CD 中的安全实践

11.1 密钥管理

CI/CD 流水线经常需要访问服务器、镜像仓库、云服务等。这些密钥不能硬编码在代码中，应该使用环境变量或密钥管理服务。

GitHub Actions 示例：

yaml

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo "$&#123;&#123; secrets.DEPLOY_KEY &#125;&#125;" > key.pem

11.2 依赖安全扫描

使用 npm audit、Snyk、Dependabot 等工具扫描依赖漏洞。

yaml

- run: npm audit --audit-level=moderate

11.3 镜像安全

Docker 镜像应该使用最小化基础镜像（如 alpine），定期更新基础镜像，扫描镜像漏洞。

十二、CI/CD 中的测试策略

12.1 测试金字塔

测试应该呈现金字塔结构：

底层：大量单元测试，快速、成本低
中层：适量集成测试
顶层：少量 E2E 测试，覆盖核心用户路径

12.2 并行化测试

在 CI 中，可以利用多个 job 或并行 runner 同时运行不同类型的测试，缩短反馈时间。

yaml

jobs:
  unit-test:
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:unit
  e2e-test:
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:e2e

12.3 测试失败的处理

CI 中测试失败时，应该：

立即通知相关人员
阻止代码合并
保留日志和截图便于排查

十三、监控与可观测性

13.1 部署后监控

CI/CD 不止到部署为止，还需要监控部署后的系统状态。常用指标：

错误率
响应时间
吞吐量
资源使用率

13.2 告警机制

当指标异常时，通过邮件、短信、Slack、钉钉等方式通知团队。

13.3 日志聚合

使用 ELK、Loki、Datadog 等工具集中收集和分析日志，快速定位线上问题。

十四、CI/CD 成熟度模型

一个团队的 CI/CD 成熟度可以分为几个阶段：

阶段一：手动部署

所有操作手动执行，容易出错。

阶段二：自动化构建和测试

代码提交后自动构建和运行测试。

阶段三：自动化部署

通过流水线自动部署到测试环境或生产环境。

阶段四：持续交付

主分支随时可部署，发布风险低。

阶段五：DevOps 文化

开发、测试、运维深度融合，快速迭代，稳定交付。

十五、常见 CI/CD 反模式

流水线过长：一个流水线跑几十分钟，反馈太慢
测试太少：没有质量门禁，问题带到线上
环境不一致：开发、测试、生产环境配置不同
发布太频繁或太少：应该小步快跑
没有回滚计划：上线出问题只能临时救火

十六、总结

CI/CD 是现代软件交付的基石。通过自动化构建、测试、部署和监控，团队可以更快、更稳地交付价值。掌握 GitHub Actions、GitLab CI、Jenkins、Docker 以及部署策略，是前端工程师走向全栈和工程化的必经之路。

十七、CI/CD 中的前端特有考量

17.1 前端构建产物

前端项目构建后通常生成静态文件（HTML、CSS、JS、图片）。这些文件需要部署到 CDN 或静态服务器上。

17.2 环境变量管理

前端代码运行在浏览器中，敏感信息不能硬编码。构建时通过环境变量注入不同环境的配置。

bash

# .env.production
VITE_API_URL=https://api.example.com

17.3 CDN 部署与缓存

前端静态资源通常部署到 CDN。需要注意：

文件名包含 hash，便于长期缓存
HTML 文件不缓存或短期缓存
回源策略和防盗链配置

十八、CI/CD 中的多端部署

18.1 Web 部署

Web 部署相对简单，构建完成后上传到服务器或对象存储即可。

18.2 小程序部署

小程序需要调用平台提供的上传接口，如微信的 miniprogram-ci。

18.3 桌面应用部署

Electron 应用需要打包成安装包，发布到官网或应用商店。

十九、GitHub Actions 高级用法

19.1 矩阵构建

矩阵构建可以同时测试多个 Node.js 版本或多个操作系统。

yaml

strategy:
  matrix:
    node-version: [18, 20]
    os: [ubuntu-latest, windows-latest]

19.2 Reusable Workflows

可复用工作流可以减少重复配置。

yaml

jobs:
  call-workflow:
    uses: ./.github/workflows/reusable.yml

19.3 Caching

缓存 node_modules 和构建产物可以显著加快 CI 速度。

yaml

- uses: actions/cache@v3
  with:
    path: node_modules
    key: $&#123;&#123; runner.os &#125;&#125;-node-$&#123;&#123; hashFiles('**/package-lock.json') &#125;&#125;

二十、总结

CI/CD 让软件交付从手工劳动变成自动化工程。一个好的 CI/CD 流程应该：

每次提交都触发自动化验证
构建和测试快速反馈
部署流程标准化、可重复
支持回滚和灰度发布
持续监控和优化

前端工程师不仅要会写代码，还要理解如何把代码安全、高效地交付到用户手中。CI/CD 正是连接开发和运营的关键环节。

二十一、GitLab CI 高级特性

21.1 Stages 与 Needs

GitLab CI 的 needs 关键字可以让 Job 不依赖上一阶段完成就开始执行，进一步缩短流水线时间。

yaml

build:
  stage: build
  script:
    - npm run build

test:
  stage: test
  needs: [build]
  script:
    - npm run test

21.2 Artifacts 传递

Artifacts 可以在不同 Job 之间传递构建产物。

yaml

build:
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 hour

21.3 Cache vs Artifacts

Cache：加速后续构建，如 node_modules
Artifacts：Job 之间传递产物，如下游 Job 使用构建结果

二十二、Jenkins 插件生态

22.1 常用插件

Blue Ocean：更友好的流水线可视化
Pipeline Stage View：查看流水线阶段
Credentials Binding：安全注入凭据
NodeJS Plugin：管理 Node.js 版本

22.2 Jenkins 与 Docker

Jenkins Pipeline 可以在 Docker 容器中运行 Job，保证环境一致性。

groovy

pipeline {
  agent {
    docker {
      image 'node:20-alpine'
    }
  }
  stages {
    stage('Build') {
      steps {
        sh 'npm ci && npm run build'
      }
    }
  }
}

二十三、CI/CD 中的数据库变更

23.1 数据库迁移

数据库变更应该通过迁移脚本管理，如使用 Flyway、Liquibase 或 ORM 的 migration 功能。

23.2 向前兼容

部署新版本时，数据库变更应该向前兼容，避免出现新旧版本同时运行时报错。

23.3 回滚策略

数据库回滚通常比代码回滚复杂。需要预先准备回滚脚本，并在非高峰时段执行变更。

二十四、CI/CD 与 DevSecOps

24.1 安全左移

把安全检查尽早集成到 CI/CD 流程中，越早发现问题，修复成本越低。

24.2 SAST 与 DAST

SAST（静态应用安全测试）：分析源代码
DAST（动态应用安全测试）：在运行时测试应用

二十五、总结

CI/CD 是现代软件工程的核心实践。它不仅提高了交付效率，更通过自动化测试、标准化流程和安全检查提升了软件质量。前端工程师应该积极参与到 CI/CD 流程的设计和优化中，理解从代码提交到线上部署的完整链路，成为真正的全栈型工程师。

二十六、CI/CD 中的环境管理

26.1 多环境策略

典型的软件交付环境包括：

开发环境（Development）：开发者本地或共享开发环境
测试环境（Testing/STAGING）：QA 测试使用
预发布环境（Staging）：与生产环境一致，用于最终验证
生产环境（Production）：真实用户访问

每个环境应该有独立的配置、数据库和域名。

26.2 环境配置分离

不要把环境配置硬编码在代码中。可以使用环境变量、配置文件或配置中心管理不同环境的差异。

bash

# .env.development
API_URL=http://localhost:8080

# .env.production
API_URL=https://api.example.com

26.3 环境一致性

Docker 和容器编排工具（如 Kubernetes）可以帮助保持各环境之间的一致性，减少"在我机器上可以运行"的问题。

二十七、CI/CD 中的通知与协作

27.1 流水线通知

当 CI/CD 流水线成功或失败时，应该及时通知团队。常用通知渠道：

企业微信
钉钉
Slack
邮件

27.2 与项目管理工具集成

可以把 CI/CD 状态与 Jira、Linear、Notion 等工具集成，实现从需求到上线的全流程跟踪。

二十八、CI/CD 的成本控制

28.1 Runner 成本

GitHub Actions、GitLab CI 的 Runner 按时间收费。可以通过以下方式节约成本：

合理设置缓存
使用自托管 Runner
避免不必要的全量构建
使用矩阵构建时控制组合数量

28.2 时间成本

流水线时间越长，反馈越慢。应该持续优化流水线速度，把反馈时间控制在合理范围内。

二十九、总结

CI/CD 是连接开发、测试、运维的纽带。一个好的 CI/CD 体系能够显著提升团队的交付能力和产品质量。前端工程师不仅要写好代码，还要理解并参与构建高效、安全、可观测的交付流程。随着 DevOps 和平台工程的发展，CI/CD 将会变得越来越重要。

领域编号：E03 CI/CD 与 DevOps
最后更新：2026-06-18

本领域学习进度

学习进度0 / 43 （0%）

CI/CD 学习文档 ​

核心要点（TL;DR） ​

学习时长与前置知识 ​

一、前言：从手工发布到自动化交付 ​

二、CI/CD 流程与价值 ​

2.1 什么是 CI？ ​

2.2 什么是 CD？ ​

2.3 CI/CD 流水线 ​

三、GitHub Actions 基础配置 ​

3.1 什么是 GitHub Actions？ ​

3.2 基础示例 ​

3.3 核心概念 ​

四、GitLab CI 基础配置 ​

4.1 什么是 GitLab CI？ ​

4.2 基础示例 ​

4.3 核心概念 ​

五、Jenkins 基础配置 ​

5.1 什么是 Jenkins？ ​

5.2 Jenkins Pipeline ​

5.3 三者对比 ​

六、Docker 基础与镜像构建 ​

6.1 什么是 Docker？ ​

6.2 Dockerfile 示例 ​

6.3 常用命令 ​

6.4 多阶段构建 ​

七、部署流水线 ​

7.1 常见部署策略 ​

7.2 自动化发布流程 ​

八、自动化测试与回滚策略 ​

8.1 自动化测试分层 ​

8.2 CI 中的测试 ​

8.3 回滚策略 ​

九、常见误区与最佳实践 ​

误区一：CI/CD 就是自动化部署 ​

误区二：测试放到上线后再补 ​

误区三：一次发布所有变更 ​

最佳实践 ​

十、总结 ​

十一、CI/CD 中的安全实践 ​

11.1 密钥管理 ​

11.2 依赖安全扫描 ​

11.3 镜像安全 ​

十二、CI/CD 中的测试策略 ​

12.1 测试金字塔 ​

12.2 并行化测试 ​

12.3 测试失败的处理 ​

十三、监控与可观测性 ​

13.1 部署后监控 ​

13.2 告警机制 ​

13.3 日志聚合 ​

十四、CI/CD 成熟度模型 ​

十五、常见 CI/CD 反模式 ​

十六、总结 ​

十七、CI/CD 中的前端特有考量 ​

17.1 前端构建产物 ​

17.2 环境变量管理 ​

17.3 CDN 部署与缓存 ​

十八、CI/CD 中的多端部署 ​

18.1 Web 部署 ​

18.2 小程序部署 ​

18.3 桌面应用部署 ​

十九、GitHub Actions 高级用法 ​

19.1 矩阵构建 ​

19.2 Reusable Workflows ​

19.3 Caching ​

二十、总结 ​

二十一、GitLab CI 高级特性 ​

21.1 Stages 与 Needs ​

21.2 Artifacts 传递 ​

21.3 Cache vs Artifacts ​

二十二、Jenkins 插件生态 ​

22.1 常用插件 ​

22.2 Jenkins 与 Docker ​

二十三、CI/CD 中的数据库变更 ​

23.1 数据库迁移 ​

23.2 向前兼容 ​

23.3 回滚策略 ​

二十四、CI/CD 与 DevSecOps ​

24.1 安全左移 ​

24.2 SAST 与 DAST ​

CI/CD 学习文档

核心要点（TL;DR）

学习时长与前置知识

一、前言：从手工发布到自动化交付

二、CI/CD 流程与价值

2.1 什么是 CI？

2.2 什么是 CD？

2.3 CI/CD 流水线

三、GitHub Actions 基础配置

3.1 什么是 GitHub Actions？

3.2 基础示例

3.3 核心概念

四、GitLab CI 基础配置

4.1 什么是 GitLab CI？

4.2 基础示例

4.3 核心概念

五、Jenkins 基础配置

5.1 什么是 Jenkins？

5.2 Jenkins Pipeline

5.3 三者对比

六、Docker 基础与镜像构建

6.1 什么是 Docker？

6.2 Dockerfile 示例

6.3 常用命令

6.4 多阶段构建

七、部署流水线

7.1 常见部署策略

7.2 自动化发布流程

八、自动化测试与回滚策略

8.1 自动化测试分层

8.2 CI 中的测试

8.3 回滚策略

九、常见误区与最佳实践

误区一：CI/CD 就是自动化部署

误区二：测试放到上线后再补

误区三：一次发布所有变更

最佳实践

十、总结

十一、CI/CD 中的安全实践

11.1 密钥管理

11.2 依赖安全扫描

11.3 镜像安全

十二、CI/CD 中的测试策略

12.1 测试金字塔

12.2 并行化测试

12.3 测试失败的处理

十三、监控与可观测性

13.1 部署后监控

13.2 告警机制

13.3 日志聚合

十四、CI/CD 成熟度模型

十五、常见 CI/CD 反模式

十六、总结

十七、CI/CD 中的前端特有考量

17.1 前端构建产物

17.2 环境变量管理

17.3 CDN 部署与缓存

十八、CI/CD 中的多端部署

18.1 Web 部署

18.2 小程序部署

18.3 桌面应用部署

十九、GitHub Actions 高级用法

19.1 矩阵构建

19.2 Reusable Workflows

19.3 Caching

二十、总结

二十一、GitLab CI 高级特性

21.1 Stages 与 Needs

21.2 Artifacts 传递

21.3 Cache vs Artifacts

二十二、Jenkins 插件生态

22.1 常用插件

22.2 Jenkins 与 Docker

二十三、CI/CD 中的数据库变更

23.1 数据库迁移

23.2 向前兼容

23.3 回滚策略

二十四、CI/CD 与 DevSecOps

24.1 安全左移

24.2 SAST 与 DAST