1、CI/CD概述：什么是CI/CD、为什么需要CI/CD、CI/CD的核心价值与收益、常见CI/CD工具对比
大家好，我是你们的讲师。今天咱们聊聊CI/CD。
说实话，我刚入行那会儿，CI/CD这个概念还挺新鲜的。那时候公司还在用手动打包、FTP上传部署的方式。每次上线，运维大哥都得熬夜盯着屏幕，生怕哪个步骤点错了。后来我接触了持续集成和持续交付，才明白——原来软件交付可以这么优雅。
什么是CI/CD？
CI/CD，全称是Continuous Integration / Continuous Delivery（或Continuous Deployment）。
咱们拆开来看：
- CI（持续集成）：开发者频繁地将代码合并到主干分支，每次合并都自动触发构建和测试。说白了，就是让代码合入这件事变得安全、快速。
- CD（持续交付/持续部署）：在CI的基础上，自动将经过测试的代码部署到类生产环境，甚至直接推送到生产环境。你想想看，如果每次代码变更都能在几分钟内自动上线，那得多爽。
我习惯用一个比喻来解释：CI就像你每天刷牙，CD就像你定期体检。刷牙（CI）保证日常清洁，体检（CD）确保整体健康。两者缺一不可。
核心要点：CI/CD不是某个工具，而是一套工程实践。它解决的是「代码从开发到上线」这个过程中的效率和质量问题。
为什么需要CI/CD？
这个问题，我当年也问过自己。直到有一次，我在项目中遇到了一个惨痛的教训。
那是一个电商项目，团队20多人，大家各自开发功能。到了上线前一周，开始合并代码。结果呢？合并冲突、编译失败、测试不通过……各种问题像多米诺骨牌一样倒下来。最后上线推迟了整整两周，老板气得拍桌子。
为什么会这样？因为大家各自为战，没有统一的集成和验证机制。
CI/CD能帮你解决这些问题：
- 减少集成痛苦：频繁集成，每次只改少量代码，冲突自然少。
- 快速发现错误：每次提交都跑测试，问题在几分钟内暴露，而不是等到上线前才发现。
- 缩短交付周期：自动化流程省去了手动操作的时间，从几天缩短到几小时甚至几分钟。
- 提升团队信心：每次部署都是经过验证的，你敢点那个「发布」按钮。
我的经验：我曾经在一个遗留项目中推行CI/CD，刚开始阻力很大。后来我选了一个小模块做试点，两周内就把部署时间从2小时降到了15分钟。团队尝到甜头后，其他模块主动要求接入。所以，别想着一步到位，先找个突破口。
CI/CD的核心价值与收益
咱们用数据说话。我整理了一个表格，对比一下有CI/CD和没有CI/CD的差异：
| 维度 | 没有CI/CD | 有CI/CD |
|---|---|---|
| 代码集成频率 | 每周/每月一次 | 每天多次 |
| 构建时间 | 手动操作，30分钟+ | 自动化，5-10分钟 |
| 测试覆盖率 | 靠人工，容易遗漏 | 自动化测试，覆盖率高 |
| 部署时间 | 手动操作，1小时+ | 一键部署，几分钟 |
| 故障发现时间 | 上线后才发现 | 提交后几分钟内 |
| 团队效率 | 运维瓶颈，开发等待 | 并行工作，高效协作 |
说白了，CI/CD的核心价值就三个字：快、稳、省。
- 快：交付速度提升，市场响应更快。
- 稳：质量有保障，线上故障减少。
- 省：减少重复劳动，人力成本降低。
注意：CI/CD不是银弹。如果你们的代码质量本身很差、测试覆盖率几乎为零，那CI/CD只会让你更快地暴露问题——但这其实是好事，因为问题早暴露比晚上线强。
常见CI/CD工具对比
市面上CI/CD工具很多，我挑三个最常用的来聊聊：Jenkins、GitLab CI、GitHub Actions。
嗯，这里要注意，选工具不是选最火的，而是选最适合你们团队和基础设施的。
| 特性 | Jenkins | GitLab CI | GitHub Actions |
|---|---|---|---|
| 部署方式 | 自托管（需维护服务器） | 自托管或SaaS | SaaS（GitHub提供） |
| 配置方式 | Web界面 + Jenkinsfile | .gitlab-ci.yml | .github/workflows/*.yml |
| 插件/生态 | 极其丰富（1000+插件） | 较丰富，但不如Jenkins | 丰富，且与GitHub深度集成 |
| 学习曲线 | 较陡峭 | 中等 | 较平缓 |
| 适合场景 | 大型企业、复杂流水线 | GitLab用户、中小团队 | GitHub用户、开源项目 |
| 成本 | 免费（但需自建服务器） | 免费版有限制，付费版功能全 | 公开仓库免费，私有仓库有额度 |
Jenkins
Jenkins是老牌工具了，我最早接触CI/CD就是用它。它的优势在于灵活性和生态。几乎你能想到的任何构建、测试、部署场景，都能找到对应的插件。但缺点也很明显——配置复杂，维护成本高。我曾经维护过一个Jenkins集群，光是插件升级和兼容性问题就够头疼的。
GitLab CI
如果你团队用的是GitLab，那GitLab CI是天然的选择。它和GitLab仓库深度集成，配置简单，用.gitlab-ci.yml文件就能定义流水线。我个人习惯在中小型项目中使用它，因为开箱即用，不需要额外搭建服务器。
GitHub Actions
GitHub Actions是后起之秀，这几年发展很快。它的最大优势是与GitHub无缝集成，而且社区提供了大量现成的Action，可以直接复用。比如你想部署到阿里云，搜一下就能找到对应的Action。我建议开源项目优先考虑它，因为公开仓库免费使用，而且生态活跃。
避坑指南：我曾经在一个项目里同时用了Jenkins和GitLab CI，结果团队分裂成两派，维护成本翻倍。后来我统一成GitLab CI，事情才理顺。所以，选一个工具，坚持用下去，比换来换去强。
小结
这一章咱们聊了CI/CD的基本概念、为什么需要它、它的核心价值，以及三个主流工具的对比。
记住一句话：CI/CD不是工具，而是文化。它需要团队从开发习惯到运维流程的全面改变。但一旦跑起来，你会发现——原来软件交付可以这么轻松。
下一章，咱们会深入Jenkins，手把手搭建一条完整的流水线。到时候见。