CI/CD

持续集成解决什么

在 CI 出现之前，团队常见的流程是：开发者各自在分支上开发几周，最后合并时才发现代码互相冲突、测试全挂，这个痛苦过程叫「合并地狱」。Martin Fowler 在 2006 年的文章里系统描述了持续集成的核心实践：每人每天至少向主干提交一次，每次提交都触发自动构建和测试，测试不通过全队优先修复。

今天 CI 的标配是：代码推送触发 GitHub Actions/GitLab CI/Jenkins 流水线，自动运行单元测试、代码风格检查、安全扫描、构建 Docker 镜像，整个过程通常在 5-15 分钟内完成，结果直接反映在 PR 页面上。[1]

持续交付与持续部署的区别

持续交付（Continuous Delivery）意味着每次构建通过后，代码已经处于「随时可以发布」的状态，但实际发布到生产需要人工点一个按钮——这个人工步骤是刻意保留的，用于做最后的业务确认。

持续部署（Continuous Deployment）则进一步把这个手工步骤也自动化：流水线测试全过，代码自动部署到生产环境，完全无需人工干预。Etsy 曾公开宣称每天部署 50 次以上。实现持续部署的前提是测试覆盖率高、监控告警完善、回滚机制快速可靠。