持续集成（Continuous Integration，CI）
相关概念
张三，李四 => 持续集成（每天至少把写好的代码集成到main主分支中一次） => 编译（maven打包）、发布、自动化测试。
CI是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。
持续集成的核心目的是尽早发现并解决问题，减少风险与浪费，提升开发敏捷性、缩短周期，保障产品上线后用户体验。
传统开发模式在模块开发完成后才集成测试，导致早期引入的 bug 到后期才暴露，定位困难，甚至需调整底层架构，严重影响进度与周期。
持续集成能在集成测试前发现问题，保障软件质量、降低风险，助力团队应对变化；其报告可清晰呈现项目进度、已实现功能、自动化测试覆盖及代码质量，让团队掌握真实项目状态。
总结
第一步，持续集成（Continuous Integration，CI）
1 提：开发人员提交编写好的代码；
2 拉：触发构建，从代码仓库拉取开发写好的代码，代码可以是 gitlab 或者 svn 都可以；
3 编：编译代码，生成 Docker 镜像或者 Jar 包等，如果是镜像，还可以配置上传到镜像仓库；
4 测：自动化测试中，可以对代码做单元测试、集成测试；
5 查：质量检查阶段，会查看流水线生成结果，把成功/失败结果反馈给开发人员；
记住五字诀：提、拉、编、测、查。后面的交付和部署，也类似。
持续交付（Continuous Delivery，CD）
相关概念
持续交付是软件开发中，以小颗粒度需求短周期频繁提交，侧重集成后在类生产环境测试并及时反馈的过程。
目的
- 开发过程的快速迭代，小步快跑，及时纠正偏离主线
- 小颗粒度实现，避免颗粒度大，出现问题解决麻烦
- 迅速反馈软件功能，避免方向性错误
- 团队角色（含客户）协作密切，减少时间浪费
总结
第二步，持续交付（Continuous Delivery，CD）
1 拿包：从 CI 接收构建产物：如 Docker 镜像或二进制文件。
2 测包：部署到测试环境，进行更复杂的测试，比如性能压测、安全漏洞扫描；
3 布包：团队确认、审批后，部署到生产环境；
持续部署（Continuous Deployment，CD）
相关概念
基于持续交付的基础上，把功能稳定，符合产品需求的版本有方法地部署至生产环境中。可以看作是持续交付的最后一环。
| 交付和部署的区别，就在于【测试环境】和【生产环境】。 |
总结
第三步，持续部署（Continuous Deployment，CD）
1 自动部署：通过工具（如 ArgoCD、Spinnaker）自动部署到生产环境；
2 监控状态：使用工具来监控系统状态，如 Zabbix、Prometheus、ELK；
3 失败回退：如果监测到故障或问题，可以在指定时间内，回退到上一版本，保证业务可用性；
持续发布（Continuous Release，CR）
相关概念
发布是周期性或不定期地对项目在部署后，进行整体软件版本的更新，例如，更新新功能或展示页面框架等。
目的
- 产品的快速迭代，小步快跑
- 适应市场变化
- 匹配市场策略
- 应对市场风险
总结
第四步，持续发布（Continuous Release，CR）
持续发布，是指周期性，或不定期地在项目部署后，进行整体软件版本的更新和发布。在这里，作为了解即可。