CI/CD 简介与持续集成基础概念
咱们先从一个最实际的问题聊起——你写代码，测试，然后合并。听起来挺简单，对吧？但就在这个过程中，我见过太多团队因为集成环节崩溃而焦头烂额。我自己也踩过坑，有一次提交了一个看似无害的小改动，结果整个 CI 环境启动就崩了，排查了大半天才发现是环境变量冲突。从那以后，我特别重视 CI/CD 的基础概念，因为这些底层逻辑对了，后面才能稳。
什么是持续集成？
持续集成，说白了就是：频繁地把代码变更合并到主干，并自动进行构建和测试。它的核心目标是尽早发现问题，而不是等到上线前一夜才发现冲突。
我记得早年做的一个项目，团队十几个人，每个人都在自己的分支上开发，一两个月才合并一次。结果每次合并都要花两天时间解决冲突，测试还经常漏掉关键错误。后来我们推行了 CI，每个提交都触发自动构建和测试，问题从“周末加班的噩梦”变成了“当天下午就能修好的小事”。
持续交付 vs 持续部署
这两个概念容易混淆。我画了个简单的对比表，你看一眼就明白：
| 概念 | 核心含义 | 是否自动部署到生产 | 典型场景 |
|---|---|---|---|
| 持续集成（CI） | 自动构建+自动测试 | 否 | 每次提交代码后自动跑单元测试 |
| 持续交付（CD） | CI + 自动部署到类生产环境 | 否（需要手动点按钮） | 自动部署到测试环境，生产环境手工确认 |
| 持续部署（CD） | CI + 自动部署到生产 | 是 | 每次通过测试的代码直接上线 |
你想想看，大部分团队其实做到 CI 就已经够用了。持续部署门槛高，需要非常完善的监控和回滚机制。我个人建议从 CI 开始，别急着一步到位。
CI 核心流程
一个典型的 CI 流水线包含这么几个环节：
- 代码提交——触发流水线
- 拉取代码——从仓库获取最新版本
- 构建——编译、打包、生成产物
- 静态检查——代码规范、安全扫描
- 单元测试——跑最快的测试
- 集成测试——混合模块一起测
- 发布——生成可部署的产物
嗯，这里要注意：很多人以为流水线越长越好，其实不然。我在项目里见过一条流水线跑了快一个小时，开发体验极差。正确做法是“快速反馈优先”，把单元测试和构建放在前面，耗时的集成测试和性能测试放在后面，甚至可以按需触发。
关键原则：每个环节保持可重复、可自动化、可追溯。如果某个环节需要人工干预，那它就不算真正的 CI。
常见工具一览
工具选择直接影响 CI 环境的稳定性。我整理了一些主流工具的特点：
| 工具 | 主要特点 | 适用场景 |
|---|---|---|
| Jenkins | 老牌、插件丰富、可自托管 | 大型企业、定制化需求高 |
| GitLab CI | 集成在 GitLab 中、配置简单 | 中小团队、全栈 CI/CD 平台 |
| GitHub Actions | 与 GitHub 无缝衔接、市场丰富 | 开源项目、小团队 |
| CircleCI | 速度优化、支持并行 | 快速迭代的 SaaS 团队 |
| Travis CI | 开源项目免费、简单 | 早期开源项目 |
我个人习惯先用 GitLab CI 或 GitHub Actions 起步，因为他们的 YAML 配置直观，出了问题也容易排查。等团队规模大了，再考虑 Jenkins 的自定义能力。
一个简单的 CI 配置示例
以 GitLab CI 为例，一个基础的流水线配置长这样：
stages:
- build
- test
- deploy
build_job:
stage: build
script:
- npm install
- npm run build
artifacts:
paths:
- dist/
test_job:
stage: test
script:
- npm run test
dependencies:
- build_job
deploy_job:
stage: deploy
script:
- echo "Deploying to staging..."
only:
- main
注意看，artifacts 可以把构建产物传递给后续阶段，避免重复构建。我曾经因为没配置 artifacts，导致测试阶段又从头编译一次，浪费了不少时间。
避坑指南
我曾经踩过一个坑：直接把测试环境配置写死在流水线里。后来一迁移服务器，所有环境变量都要改，排查到崩溃。从那以后，我坚持把所有敏感信息（、数据库密码、环境差异）都用 CI 的变量管理功能，再也不要硬编码。
还有一个常见问题：依赖缓存。如果你用的包管理工具（npm、pip、maven）没有配置缓存，每次构建都会重新下载依赖，直接拉长流水线几分钟。我建议在 CI 配置中加上缓存策略，比如 GitLab CI 的 cache 关键字：
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
本章知识体系
为了让你对整体有个直观印象，我画了一张流程图，把 CI/CD 的核心概念串联起来：
实践要点总结
- 快速反馈——流水线越短越好，10分钟内给出结果
- 可重复环境——用容器化（Docker）统一开发、测试、生产环境
- 分支策略——建议用 Trunk-based 或短生命特性分支，别让分支活太久
- 失败优先——一旦构建失败，立即停止下游流程，通知相关人
一个小建议：第一次搭建 CI 时，别追求完美。先跑通最简单的“提交即构建”，再逐步加测试、加代码检查。我见过不少团队一开始就想把所有环节都塞进去，结果光调配置就花了一周，反而失去了启动的动力。
好了，这一章的基础概念就聊到这里。后面我们会深入 CI 环境启动时崩溃的具体场景，以及如何用持续集成的手段去排查和修复。到时候我会分享更多真实案例，包括我自己遇到的那些“血泪教训”。