从提交到可部署产物
持续集成要求每次变更都合入共享分支并触发自动构建与测试。持续交付进一步产出可部署产物并推过预发环境；持续部署再进一步自动发布。流水线是一份契约：只要它是绿的，产物就可发布。
push -> 安装依赖(带缓存) -> lint -> 单元测试 -> 构建 -> 集成测试
-> 推送镜像 -> 部署预发 -> 冒烟测试 -> [门禁] -> 生产何时使用
当不止一个人向同一代码库提交时，就应引入 CI/CD；当发布频率高于每月一次时，应视为必需。它同样适用于 Web 服务、库和移动应用。单人项目若每季度发布一次，轻量流水线也够用，但快速反馈仍然值得。
权衡
流水线需要工程时间与基础设施投入。缓慢的测试套件会侵蚀信任，而不稳定的测试比没有测试更糟，因为它教人忽略红色构建。安全扫描与审批会增加门禁，但必须足够快以免阻塞。回报是更小的批次、更快的定位，以及不再依赖英雄主义的日常发布。
示例与常见误解
某团队把流水线拆成快速阶段（lint 与单元测试五分钟内完成）和慢速阶段（集成与端到端测试），开发者在切换任务前就能拿到反馈。认为 CI/CD 一律等于自动部署到生产的误解，混淆了持续交付与持续部署。相关概念包括构建缓存、GitOps 与滚动部署。