一、流水线概述：CI/CD 到底是什么？
说实话，我刚入行那会儿，对 CI/CD 的理解也很模糊。总觉得不就是自动编译、自动部署嘛，有啥好讲的？直到我在一个创业公司踩了大坑——每次上线都是手动操作，半夜三点还在盯着屏幕等部署结果，那种滋味，嗯，真不好受。
今天我就用大白话，把 CI/CD 这件事给你讲透。
1.1 什么是 CI（持续集成）？
CI，全称 Continuous Integration，翻译过来叫「持续集成」。说白了就是：你每次提交代码，系统自动帮你做两件事——编译 + 测试。
我见过太多团队，开发写完代码往仓库一推，然后就不管了。等到周五合并代码时，发现冲突一大堆，编译都过不了。这就是典型的「集成的地狱」。
CI 的核心价值：尽早发现问题，而不是等到上线前才手忙脚乱。
举个例子，你写了一个新功能，提交到 Git 仓库。这时候 CI 系统会自动拉取代码，执行：
- 代码编译（能不能跑起来？）
- 单元测试（逻辑对不对？）
- 代码规范检查（风格统一吗？）
- 安全扫描（有没有漏洞？）
整个过程几分钟搞定。如果哪一步失败了，系统会立刻通知你。你想想看，这比等到上线前才发现问题，省了多少时间？
1.2 什么是 CD（持续交付/持续部署）？
CD 有两个意思，我分开讲：
- 持续交付（Continuous Delivery）：代码通过 CI 后，自动部署到测试环境。人工确认后，再手动触发生产部署。
- 持续部署（Continuous Deployment）：更激进一点——代码通过所有测试后，自动部署到生产环境，不需要人工干预。
我个人习惯把 CD 理解为「让软件随时处于可发布状态」。你想想，如果每次上线都要折腾半天，那还谈什么敏捷开发？
我的建议：刚开始做自动化流水线，先做到 CI + 持续交付就够了。持续部署风险较高，等团队成熟了再考虑。
1.3 为什么需要自动化流水线？
这个问题，我用一个真实案例来回答。
我曾经在一个传统企业做咨询，他们的上线流程是这样的：
- 开发写完代码，打包成 war 包
- 用 U 盘拷贝到跳板机
- 手动停掉 Tomcat
- 替换 war 包
- 手动启动 Tomcat
- 观察日志，确认启动成功
整个过程大概 30 分钟，而且经常出错。有一次运维小哥把测试环境的包部署到了生产环境，导致线上挂了 2 小时。
自动化流水线能解决什么问题？
- 消除人为失误：机器不会手抖，不会搞错环境
- 提升效率：30 分钟的手动操作，自动化后可能只要 3 分钟
- 可重复性：每次部署流程完全一致，结果可预期
- 快速反馈：代码提交后几分钟就知道有没有问题
注意：自动化不是万能的。如果代码质量本身很差，流水线再漂亮也没用。工具只是辅助，核心还是人的习惯和流程。
1.4 常见 CI/CD 工具对比
市面上 CI/CD 工具很多，我挑三个最主流的来讲：Jenkins、GitLab CI、GitHub Actions。
先看一张对比表：
| 特性 | Jenkins | GitLab CI | GitHub Actions |
|---|---|---|---|
| 部署方式 | 自托管（需安装） | 自托管 / SaaS | SaaS（云端） |
| 配置方式 | Web UI / Jenkinsfile | .gitlab-ci.yml | .github/workflows/*.yml |
| 插件生态 | 极其丰富（2000+） | 中等 | 丰富（Marketplace） |
| 学习曲线 | 较陡 | 中等 | 较平缓 |
| 适合场景 | 大型企业、复杂流水线 | GitLab 深度用户 | GitHub 用户、开源项目 |
| 成本 | 免费（需自建服务器） | 免费版有限制 | 公开仓库免费 |
Jenkins
老牌工具，功能强大到没朋友。我最早接触 CI/CD 就是用的 Jenkins。它的插件生态太丰富了，几乎你能想到的集成方式都有插件支持。
但说实话，Jenkins 的配置确实有点复杂。我记得第一次搭 Jenkins 流水线，光是装插件就花了大半天。而且 UI 界面嘛...嗯，懂的都懂。
适合谁用？大型企业、有专职运维的团队、需要高度定制化的场景。
GitLab CI
如果你团队用 GitLab 管理代码，那 GitLab CI 就是天然的选择。它和 GitLab 深度集成，配置都在 .gitlab-ci.yml 文件里，代码即配置。
我个人很喜欢 GitLab CI 的 Runner 机制——你可以用自己的机器跑流水线，也可以直接用 GitLab 提供的共享 Runner。灵活性很高。
适合谁用？GitLab 用户、中小团队、不想折腾 Jenkins 的人。
GitHub Actions
这个是我现在用得最多的。GitHub Actions 的体验真的很好，配置简单，Marketplace 里现成的 Action 一搜一大把。
举个例子，你想部署到阿里云 ECS，直接搜「aliyun ecs action」，找到合适的直接引用就行，不用自己写脚本。
适合谁用？GitHub 用户、开源项目、个人开发者、小团队。
我的建议：别纠结选哪个工具。先选一个你用得最顺手的，把流水线跑起来再说。工具可以换，但自动化的思维才是核心。
1.5 本章知识体系
下面这张图，帮你理清本章的核心逻辑：
这张图把 CI、CD 和工具的关系理清楚了。你从左往右看，就是一条完整的流水线：代码提交 → CI 检查 → CD 部署 → 工具支撑。
好了，这一章就讲到这里。记住一句话：自动化流水线不是银弹，但它能帮你省下 80% 的重复劳动。下一章我们开始动手搭建第一条流水线。