CI/CD 面试题

本面试题基于《CI/CD 学习文档》编写，按难度分为基础、进阶、高级三个等级，每题均附详细参考答案与评分要点，适用于前端工程化、DevOps 相关岗位面试与技术评估。

---

一、基础题

0. 第 1 题基础

第 1 题

请解释 CI 和 CD 的区别，CD 有哪两种常见含义？

参考答案：

• CI（Continuous Integration，持续集成）：开发人员频繁地将代码合并到主干分支，每次合并都自动触发构建和测试。核心价值是早发现早修复、减少分支冲突、自动化验证。

• CD 有两种常见含义：

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

评分维度：

• 能解释 CI 概念（30%）
• 能区分两种 CD 含义（50%）
• 说明人工确认与自动部署的差异（20%）

---

0. 第 2 题基础

第 2 题

请简述 GitHub Actions 中 Workflow、Job、Step、Action、Runner 的概念。

参考答案：

• Workflow（工作流）：一个 YAML 文件对应一个工作流，定义自动化流程。
• Job（任务）：工作流中的执行单元，多个 Job 可以并行执行。
• Step（步骤）：Job 中的具体命令或 Action 调用。
• Action（动作）：可复用的步骤，如 actions/checkout、actions/setup-node。
• Runner（运行器）：执行 Job 的机器，可以是 GitHub 托管的或自托管的。

评分维度：

• 能说出五个概念定义（70%）
• 能举例说明 Action 和 Runner（30%）

---

0. 第 3 题基础

第 3 题

GitLab CI 中 Stage 和 Job 有什么关系？

参考答案：

• Pipeline（流水线）：由多个 Stage 组成。
• Stage（阶段）：流水线的阶段，同一 Stage 中的 Job 并行执行，不同 Stage 顺序执行。
• Job（任务）：具体执行单元，属于某个 Stage。

例如：

stages:
  - test
  - build
  - deploy

test 阶段的所有 Job 先并行执行，全部通过后再进入 build 阶段。

评分维度：

• 能解释 Pipeline/Stage/Job 三层结构（50%）
• 说明同阶段并行、不同阶段顺序执行（40%）
• 能举例说明（10%）

---

0. 第 4 题基础

第 4 题

请对比 GitHub Actions、GitLab CI、Jenkins 的适用场景。

参考答案：

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

GitHub Actions 适合 GitHub 托管项目，开箱即用；GitLab CI 与 GitLab 深度集成；Jenkins 适合需要高度定制、私有部署和复杂插件生态的企业环境。

评分维度：

• 能从托管方式、配置语言、生态对比（50%）
• 能给出适用场景建议（40%）
• 不片面推崇某一工具（10%）

---

0. 第 5 题基础

第 5 题

Docker 容器化相比传统部署有什么优势？

参考答案：

Docker 把应用及其运行环境打包成镜像，确保运行结果一致。

优势：

• 环境一致性：开发、测试、生产环境一致，避免"在我机器上可以运行"；
• 快速部署：镜像启动快，便于扩展；
• 隔离性：不同应用运行在不同容器中，互不干扰；
• 可移植性：一次构建，到处运行；
• 版本可控：镜像可版本化，便于回滚。

评分维度：

• 能解释容器化概念（20%）
• 能说出至少 4 个优势（60%）
• 结合实际场景说明（20%）

---

0. 第 6 题基础

第 6 题

请解释蓝绿部署、金丝雀发布、滚动部署的区别。

参考答案：

• 蓝绿部署：同时维护两套环境（蓝和绿），一套对外服务，另一套部署新版本。验证通过后切换流量。特点是切换快、回滚快，但需要双倍资源。
• 金丝雀发布：先让一小部分用户访问新版本，观察没有问题后逐步扩大流量。特点是风险可控、发布渐进，但需要完善的监控和流量控制能力。
• 滚动部署：逐个替换旧实例为新实例，不需要额外资源，但回滚较慢，且发布过程中新旧版本并存。

评分维度：

• 能分别解释三种策略（60%）
• 能对比资源占用、回滚速度、风险（30%）
• 能给出选择建议（10%）

---

0. 第 7 题基础

第 7 题

什么是测试金字塔？在 CI 中如何应用？

参考答案：

测试金字塔是一种测试分层理念：

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

在 CI 中应用：

• 每次提交自动运行单元测试，保证快速反馈；
• 合并前运行集成测试和 E2E 测试；
• 设置测试覆盖率门禁；
• 并行执行不同类型的测试，缩短流水线时间。

评分维度：

• 能描述测试金字塔三层结构（50%）
• 能结合 CI 流程说明应用方式（50%）

---

二、进阶题

0. 第 8 题进阶

第 8 题

GitHub Actions 中 cache 和 actions/cache 有什么区别？如何合理使用缓存？

参考答案：

• actions/setup-node 等 Action 自带的 cache 参数：简化了 npm/yarn/pnpm 依赖缓存配置。
• actions/cache：更通用的缓存 Action，可以缓存任意路径，如 node_modules、构建产物、工具链等。

合理使用缓存：

• 缓存依赖安装结果，如 ~/.npm 或 node_modules；
• 缓存构建产物，避免重复构建未变更部分；
• 使用 hashFiles 根据 lock 文件生成缓存 key，确保依赖变化时刷新缓存；
• 设置 restore-keys 实现缓存回退；
• 注意缓存大小限制和失效策略。

评分维度：

• 能区分内置 cache 和 actions/cache（40%）
• 能给出缓存使用建议（50%）
• 提到 key 设计和 restore-keys（10%）

---

0. 第 9 题进阶

第 9 题

GitLab CI 中 cache 和 artifacts 有什么区别？

参考答案：

• Cache：用于加速后续构建，如缓存 node_modules。Cache 是跨 Pipeline 共享的，可以提高重复构建速度。
• Artifacts：用于在同一个 Pipeline 的不同 Job 之间传递产物，如 build 阶段生成的 dist/ 传递给 deploy 阶段。

区别总结：

特性	Cache	Artifacts
作用	加速后续构建	Job 间传递产物
生命周期	跨 Pipeline	通常当前 Pipeline 内
典型内容	node_modules	dist、报告文件
过期策略	按 key 和策略	expire_in

评分维度：

• 能分别解释 cache 和 artifacts（50%）
• 能用表格或文字对比差异（40%）
• 举例说明典型用法（10%）

---

0. 第 10 题进阶

第 10 题

Jenkins Pipeline 中，agent any 和 agent { docker { image 'node:20' } } 有什么区别？

参考答案：

• agent any：任意可用的 Jenkins agent 都可以执行该 Pipeline，使用 agent 上的默认环境。
• agent { docker { image 'node:20' } }：在指定的 Docker 容器中执行 Pipeline，自动拉取 node:20 镜像并在其中运行所有步骤。

使用 Docker agent 的优势：

• 环境一致性高；
• 不需要在 Jenkins agent 上安装 Node.js 等工具；
• 不同项目可以使用不同版本的运行环境，互不干扰。

评分维度：

• 能解释两种 agent 配置（50%）
• 能说明 Docker agent 的优势（40%）
• 提到环境隔离（10%）

---

0. 第 11 题进阶

第 11 题

CI/CD 中如何保证密钥安全？请举例说明。

参考答案：

1. 不硬编码密钥：绝不在代码中直接写入密码、Token、私钥。
2. 使用环境变量：在 CI/CD 平台中配置 Secrets，通过环境变量注入。
3. 使用密钥管理服务：如 AWS Secrets Manager、Azure Key Vault、HashiCorp Vault。
4. 最小权限原则：只授予流水线完成任务所需的最小权限。
5. 定期轮换密钥：避免长期使用同一密钥。

GitHub Actions 示例：

jobs:
  deploy:
    steps:
      - run: echo "${{ secrets.DEPLOY_KEY }}" > key.pem

评分维度：

• 能说出至少 4 条安全措施（60%）
• 能举例说明 GitHub Actions 的 secrets 使用（30%）
• 强调不硬编码（10%）

---

0. 第 12 题进阶

第 12 题

前端项目 CI/CD 有哪些特有考量？

参考答案：

1. 构建产物：前端构建后生成静态文件，需要部署到 CDN 或静态服务器。
2. 环境变量管理：前端代码运行在浏览器，敏感信息不能硬编码，构建时通过环境变量注入。
3. CDN 部署与缓存：
   • JS/CSS 文件名包含 hash，便于长期缓存；
   • HTML 文件不缓存或短期缓存；
   • 配置回源策略和防盗链。
4. 多端部署：Web、小程序、桌面应用等不同端有不同的部署方式。
5. 构建体积优化：需要在 CI 中监控产物体积，防止包体积过大。

评分维度：

• 能说出前端构建产物和部署特点（40%）
• 提到环境变量和 CDN 缓存策略（40%）
• 说明多端部署和体积监控（20%）

---

0. 第 13 题进阶

第 13 题

请描述一个完整的 CI/CD 流水线应包含哪些环节。

参考答案：

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

1. 代码提交：开发者提交代码并推送；
2. 拉取代码：CI/CD 工具检出代码；
3. 安装依赖：安装项目依赖；
4. 代码检查：运行 ESLint、Prettier、类型检查；
5. 自动化测试：单元测试、集成测试、E2E 测试；
6. 构建项目：编译打包生成产物；
7. 镜像打包：构建 Docker 镜像并推送镜像仓库；
8. 部署：部署到测试/预发布/生产环境；
9. 线上验证：健康检查、监控告警。

评分维度：

• 能按顺序说出至少 7 个环节（70%）
• 能说明每个环节的作用（20%）
• 提到质量门禁和监控（10%）

---

0. 第 14 题进阶

第 14 题

什么是 CI/CD 成熟度模型？你的团队目前可能处于哪个阶段？

参考答案：

CI/CD 成熟度可分为五个阶段：

1. 阶段一：手动部署：所有操作手动执行，容易出错。
2. 阶段二：自动化构建和测试：代码提交后自动构建和运行测试。
3. 阶段三：自动化部署：通过流水线自动部署到测试或生产环境。
4. 阶段四：持续交付：主分支随时可部署，发布风险低。
5. 阶段五：DevOps 文化：开发、测试、运维深度融合，快速迭代，稳定交付。

不同团队所处阶段不同，面试者应结合实际项目经验说明当前阶段及下一步改进方向。

评分维度：

• 能按顺序说出五个阶段（50%）
• 能结合自身项目说明所处阶段（30%）
• 提出改进方向（20%）

---

三、高级题

0. 第 15 题深入

第 15 题

请设计一个前端项目的完整 CI/CD 方案，包括分支策略、测试策略、部署策略和回滚策略。

参考答案：

1. 分支策略：

   • 使用 Git Flow 或 Trunk-Based Development；
   • main 分支为发布分支，必须保持可部署；
   • 功能开发通过 feature 分支 + Pull Request 合并。

2. 测试策略：

   • PR 时运行 lint、类型检查、单元测试；
   • 合并到 main 后运行集成测试和 E2E 测试；
   • 设置测试覆盖率门禁；
   • 使用并行 Job 缩短反馈时间。

3. 部署策略：

   • 测试环境：每次合并自动部署；
   • 预发布环境：通过手动触发或标签触发；
   • 生产环境：使用金丝雀发布，逐步放量；
   • 静态资源部署到 CDN，HTML 部署到对象存储或服务器。

4. 回滚策略：

   • 代码回滚：快速 revert 并重新部署；
   • 镜像回滚：重新部署上一个稳定镜像；
   • 流量回滚：通过金丝雀/蓝绿快速切回旧版本；
   • 数据库变更保持向前兼容，便于回滚。

评分维度：

• 四个方面均有涉及（60%）
• 每个方面给出具体措施（30%）
• 方案整体可落地、有连贯性（10%）

---

0. 第 16 题深入

第 16 题

如何优化 CI/CD 流水线的执行时间？请至少列举 6 种方法。

参考答案：

1. 并行执行：将 lint、test、build 等任务拆分为并行 Job。
2. 缓存依赖：缓存 node_modules 或包管理器缓存目录。
3. 缓存构建产物：利用 Turborepo/Nx 远程缓存。
4. 按需构建：只构建受影响的项目或文件。
5. 精简测试：使用 affected 测试，避免全量测试。
6. 使用轻量镜像：如 Alpine 基础镜像，减少拉取时间。
7. 减少矩阵组合：矩阵构建时控制 Node.js 版本和操作系统组合数量。
8. 优化构建配置：如启用 Webpack 5 持久化缓存、使用 esbuild。

评分维度：

• 能说出至少 6 种方法（80%）
• 能结合实际场景说明（20%）

---

0. 第 17 题深入

第 17 题

CI/CD 中数据库变更如何处理？为什么数据库回滚通常比代码回滚复杂？

参考答案：

数据库变更处理：

• 使用迁移脚本管理数据库变更，如 Flyway、Liquibase、ORM migration；
• 变更脚本纳入版本控制，和代码一起 review；
• 部署新版本时，数据库变更应向前兼容，避免新旧版本同时运行时报错；
• 非高峰时段执行变更，降低影响。

数据库回滚复杂的原因：

• 数据可能已经发生变化，无法简单回退；
• 回滚脚本需要预先准备，且要经过充分测试；
• 数据库回滚可能影响数据一致性；
• 需要协调代码回滚和数据库回滚的顺序。

评分维度：

• 能说明迁移脚本和版本控制（30%）
• 提到向前兼容和非高峰执行（30%）
• 能解释数据库回滚复杂性（40%）

---

0. 第 18 题深入

第 18 题

什么是 DevSecOps？如何在 CI/CD 中实现安全左移？

参考答案：

DevSecOps：将安全实践融入 DevOps 流程中，让安全成为开发和运维的一部分，而不是最后的关卡。

安全左移实践：

1. 依赖安全扫描：使用 npm audit、Snyk、Dependabot、OSV 扫描依赖漏洞，阻断高风险依赖合并。
2. 静态应用安全测试（SAST）：使用 SonarQube、CodeQL 分析源代码中的安全漏洞。
3. 动态应用安全测试（DAST）：在运行时测试应用安全，如 OWASP ZAP。
4. 镜像安全扫描：扫描 Docker 镜像漏洞，使用最小化基础镜像（distroless/Alpine）。
5. 密钥管理：不在代码中硬编码密钥，使用 Secrets 管理、短期凭证、密钥轮换。
6. 代码审查：将安全 review 纳入 PR 流程，重点关注输入校验、认证授权、敏感信息。
7. 基础设施安全：IaC 扫描、容器权限最小化、网络隔离。

评分维度：

• 能解释 DevSecOps 和安全左移（35%）
• 能说出至少 4 种实践（45%）
• 提到 SAST/DAST/镜像扫描/密钥管理等具体手段（20%）

---

0. 第 19 题深入

第 19 题

CI/CD 流水线失败时，应该如何处理？

参考答案：

1. 立即通知：通过邮件、Slack、钉钉等通知相关人员。
2. 保留日志和产物：保存失败日志、截图、构建产物，便于排查。
3. 阻止代码合并：测试失败时阻止 PR 合并，保证主分支稳定。
4. 快速定位问题：
   • 查看失败步骤的日志；
   • 判断是代码问题、环境问题还是 flaky test；
   • 本地复现问题。
5. 修复并重新触发：修复后重新运行流水线，确保通过。
6. 复盘总结：对频繁失败的流水线进行优化，如优化 flaky test、加速构建等。

评分维度：

• 能说出通知、保留日志、阻止合并等关键动作（50%）
• 能说明定位和修复流程（40%）
• 提到复盘优化（10%）

---

0. 第 20 题深入

第 20 题

请从成本、效率、安全三个维度，分析如何建设和优化 CI/CD 体系。

参考答案：

1. 成本：

   • 合理设置缓存，减少重复下载和构建；
   • 使用自托管 Runner 降低 SaaS 费用；
   • 控制矩阵构建组合数量；
   • 按需构建，避免不必要的全量构建。

2. 效率：

   • 并行执行无依赖任务；
   • 使用构建缓存和远程缓存；
   • 精简测试范围，使用 affected 测试；
   • 优化构建配置和镜像体积。

3. 安全：

   • 密钥不硬编码，使用 Secrets 管理；
   • 依赖和镜像安全扫描；
   • 最小权限原则配置 Runner 权限；
   • 分支保护和代码审查；
   • 定期轮换密钥和审计流水线。

建设和优化 CI/CD 需要持续投入，根据团队规模、项目特点和业务需求不断调整。

评分维度：

• 三个维度均有涉及（60%）
• 每个维度给出具体措施（30%）
• 强调持续优化（10%）

---

难度分布总结

难度	题号	数量
基础	1-7	7
进阶	8-14	7
高级	15-20	6
合计	—	20

---

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