ci是集成验证，每次push后自动拉代码、编译、测单元、扫质量；cd是交付决策，分人工确认上线（delivery）与全自动上线（deployment），核心在于“谁按上线键”；devops是支撑ci/cd落地的协作机制与环境一致性保障。
CI 是“集成验证”，CD 是“交付决策”
CI 的核心动作是：每次 git push 后，自动拉代码 → 编译 → 运行单元测试 → 扫描代码质量（如 SonarQube）。它不关心部署到哪，只回答一个问题：“这段代码和主干还能一起跑吗？”
CD 则是在 CI 通过后介入：把构建好的制品（比如 Docker 镜像或 jar 包）推到预发/生产环境，但它分两种路径：
• Continuous Delivery：自动发布到 staging 环境，上线生产需人工点确认按钮（金融、政务系统常用）
• Continuous Deployment：测试全过就自动 kubectl apply 或 aws deploy 到 production（SaaS 产品常见）
关键区别在于“谁按那个上线键”——CI 没有这个键，CD 定义了这个键由人按还是机器按。
DevOps 不是 CI/CD 的上级菜单，而是让 CI/CD 跑得通的土壤
很多团队搭好 Jenkins 或 GitHub Actions 流水线，却卡在“测试过了但运维不让上生产”。这不是工具问题，是 DevOps 缺位的表现。
真实落地时，CI/CD 要生效，必须满足三个隐性条件：
• 开发写的部署脚本（如 deploy.sh）能被运维审核并信任
• 测试环境和生产环境用同一套 Dockerfile + 同一版 Kubernetes 集群配置（靠 Terraform 或 Ansible 管理）
• 运维参与定义“什么算测试通过”——比如要求 覆盖率 ≥ 80% 且 critical 级别漏洞 = 0，而不是只看 test passed
没这些，CI/CD 就只是开发自嗨的自动化玩具。
最容易踩的坑：把 CD 当成“一键上线”，忽略环境与权限断层
典型失败场景：
• 在本地用 docker build 成功，流水线里却报 npm ERR! code EACCES（CI 环境没配 node 用户权限）
• GitHub Actions 能把镜像推到 Harbor，但没给运维开通该镜像仓库的 pull 权限，导致 k8s 拉不到镜像，Pod 卡在 ImagePullBackOff
• 测试环境用 mock API，CD 流程里忘了切回真实 prod config，上线后所有请求 502
解决思路不是加更多自动化，而是把环境差异、密钥管理、配置切换这些“非代码部分”显式纳入流水线——比如用 envsubst 替换模板，用 HashiCorp Vault 注入 secrets，而不是写死在 .yml 里。
CI/CD 真正难的从来不是写 YAML 或配 webhook，而是让开发敢改部署逻辑、让运维愿接自动化结果、让 QA 能在 pipeline 里插桩验证业务逻辑。工具链再新，缺了这三层对齐，流水线就只是个会自己跑的报错器。
