CI/CD 实战与面试
目标：讲清流水线在干什么，并能描述一条「提交代码 → 构建测试 → 部署」的最小路径。
面试高频问法
- 什么是 CI？什么是 CD？你们流水线有哪些阶段？
- 你们常用哪种 CI/CD 方式？为什么适合你们场景？
- 一次提交后，你们服务器/环境怎么更新？
- 构建失败你怎么查？发布失败怎么回滚？
- 有没有做过分支策略？（main / feature / release）
- 密钥、环境变量怎么管理？会不会打进镜像？
- 持续交付和持续部署有什么区别？生产要不要人工确认？
口述参考（短版）
CI： 代码合并后自动构建 + 跑测试，尽早发现问题。
CD： 把可发布产物自动推到测试/预发；生产是否全自动取决于团队，很多公司保留人工确认。
一条典型流水线：
checkout → 安装依赖/编译 → 单测 → 打包（jar/镜像）→ 部署到环境 → 健康检查。
回滚： 保留上一版产物/镜像 tag；出问题切回上一版本并观察健康检查与日志。
常用方式有哪些，各自适用什么场景
面试别只背工具名，要说清：我们用什么、为什么适合这个团队、边界在哪。
1）按工具平台（选一个你真实接触过的深讲）
| 方式 | 常见形态 | 更适合 | 不太适合 / 注意 |
|---|---|---|---|
| GitHub Actions | 仓库内 YAML，按 push / PR / tag 触发 | 开源、GitHub 托管、个人/小团队、本站这种静态站发布 | 强内网隔离、极重的私有构建机需求 |
| GitLab CI | .gitlab-ci.yml + Runner | 自建 GitLab、代码与流水线一体、国内很多企业仓库 | Runner 要自己维护；权限和缓存要规划 |
| Jenkins | 可视化 Job / Pipeline as Code | 老项目、复杂多仓库编排、公司已有 Jenkins 机房 | 插件多易变脆；要从零选型时不一定是首选 |
| 云厂商流水线（阿里云效 / 腾讯 Coding / 华为等） | 和云主机、镜像仓库、K8s 绑得紧 | 业务已在该云、要少运维 | 易被厂商锁定；换云成本高 |
| 手动 / 半自动 | 本机构建 + 脚本上传 / 宝塔 / 远程 ssh | 早期项目、一人维护、发布频率低 | 难复现、难协作；面试要承认并说清演进方向 |
口述模板：
我们常用的是 XXX。触发方式是合并到某分支后自动构建打包，测试环境自动部署；生产需要人工点确认。选它是因为仓库就在这套体系里，维护成本低。
2）按发布节奏（CI 之后「送到哪、谁点确认」）
| 方式 | 含义 | 适用场景 |
|---|---|---|
| 只做 CI | 自动构建 + 测试，部署仍人工 | 规范刚起步；生产变更敏感；人少但要先保证「合并不烂」 |
| Continuous Delivery（持续交付） | 随时可发布，生产通常人工确认 | 大多数业务系统、MES / 企业后台——最常见、也好讲 |
| Continuous Deployment（持续部署） | 通过流水线后自动上生产 | 强自动化、完善测试与监控的团队；小工具/静态站也可以 |
| 定时发布 | 每天/每周固定窗口发版 | 强监管、需变更窗口；避免深夜随意发 |
注意：面试里 Delivery ≠ Deployment。很多公司说「我们做了 CD」，实际是 Delivery（可发，但生产要人点）。
3）按部署策略（生产怎么换版本）
| 方式 | 怎么做 | 适用场景 | 代价 |
|---|---|---|---|
| 停机更新 | 停旧 → 上新 → 验证 | 内部系统、可接受短暂停机、发布少 | 简单，但有中断 |
| 滚动更新 | 分批替换实例 | 多实例服务、要不停服 | 要健康检查；兼容旧新并存 |
| 蓝绿部署 | 两套环境切换流量 | 要快速回滚、发布窗口紧 | 资源占用约翻倍 |
| 金丝雀 / 灰度 | 先放一小部分流量 | 用户多、风险高、要观察指标 | 要网关/流量与监控配合 |
结合你的方向可以这样说：
企业业务系统和 MES 类项目，我更常见的是 持续交付 + 测试环境自动部署 + 生产人工确认；实例不多时滚动或短停机更新都能接受。蓝绿/灰度要有多实例和流量切换能力才划算。
4）按触发方式（流水线什么时候跑）
| 触发 | 适用 |
|---|---|
| Push / 合并到开发分支 | 日常 CI：编译、单测、打测试包 |
| Merge Request / Pull Request | 合入前卡质量（必跑检查） |
| 打 Tag / Release | 出正式版本、部署预发/生产 |
| 手动点击（Manual job） | 生产发布、危险操作、数据迁移 |
| 定时（Cron） | 夜间全量回归、定期构建依赖缓存 |
实战：你要能讲清的最小落地
不必背 Jenkins 全插件。抓住你真实用过的一种即可（GitHub Actions / GitLab CI / Jenkins），并用上一节的表说清「为什么选它、发布到哪一步自动、哪一步要人」。
流水线阶段（按这个记）
| 阶段 | 做什么 | 失败了怎么办 |
|---|---|---|
| 构建 | 编译、打 jar/镜像 | 看编译日志、依赖、JDK 版本 |
| 测试 | 单测/关键冒烟 | 先修测试或确认是否环境不稳 |
| 发布 | 拷贝产物或拉镜像启动 | 回滚上一版本、看启动日志 |
| 验证 | 健康检查、核心接口探活 | 不通过则停止放量/回滚 |
口述模板（套你自己的项目）
我们一般是提交到主开发分支后触发流水线：先构建打包，再跑基础测试，通过后部署到测试环境。生产发布会确认版本号。出问题优先看流水线日志和容器/服务启动日志，必要时回滚到上一个稳定包。
安全底线（加分）
- 密码、Token 走环境变量/密钥管理，不写死在仓库
- 不同环境（dev/test/prod）配置分离
- 镜像打 tag（别只会
latest）
结合你简历怎么讲
若有 Docker + CI/CD（如 MES）：
依赖服务容器化，业务包通过流水线构建；发布后看服务是否起来、关键接口是否通。发布异常会停更并回滚。
没完整流水线也如实说：
目前更多是手动/半自动发布，但我清楚标准流水线该有构建、测试、部署、回滚，正在往自动化补齐。
比硬编一整套 Jenkins 更稳。
常见坑
- 「流水线绿了但服务没起来」——缺健康检查
- 本地能过、CI 失败——JDK/Node 版本不一致
- 配置打进镜像——换环境要重新构建，还容易泄密
自测清单
- [ ] 能画/能说 5 个阶段：取代码→构建→测试→部署→验证
- [ ] 能说出至少 2 种常用平台，并各举一个适用场景
- [ ] 能区分持续交付 vs 持续部署，以及你们生产要不要人点确认
- [ ] 能说出停机 / 滚动 / 蓝绿大致适用什么情况
- [ ] 能说一次构建失败或发布回滚经历（真实即可）
- [ ] 知道密钥不该进 Git
- [ ] 能区分 CI 和 CD 各解决什么问题