一、概念辨析——持续集成、持续交付与持续部署

1. 持续集成（Continuous Integration CI）

    在软件开发领域，持续集成指频繁地将较小的代码改动正确的合并到共享的发布（或者叫主）分支上。

    开发一个软件就好比造一辆汽车，每个研发负责其中一个模块，汽车的不同模块组装的地方叫代码服务器，研发同学提交代码就是把自己研发的模块集成到这个汽车上。
    软件开发早期，协商好各个模块的规格后（软件接口），每个模块的同学就可以闷头开发去了，最后所有模块开发完毕，大家把所有部分拿到一起进行集成组装。但这样有一个问题，一个模块的规格（对外接口）一旦确定，就不能改变，如果改变或者开发错误，最后集成阶段就不能跟其他模块兼容，需要耗费大量精力返工，这种模式与当前互联网快速开发、试错的节奏不符合。
    这时候持续集成方案出现了，在这个方案下，虽然可能还是跟之前的模块分工差不多，但是要求研发尽量把自己开发的功能原子化，并多次提交。每次代码提交都会触发构建、代码检查、测试流程，旨在快速发现不同开发者之间的代码冲突和接口兼容性问题。这种方案下模块之间的接口可以快速的修改、对齐，这样整个系统架构就能够快速演化；同时每一次的集成都通过代码检查、测试等保证了基础的质量，使得整个软件的演进阶段几乎每个时刻都有一个质量还过的去的可用版本。

    虽然持续集成无法消除bug，但却能让“bug变的小一点“，降低修复bug的难度和时间，遇到解决不了问题，也能及时回退代码。

• 核心目标：通过高频代码检查、合入，降低后期大规模代码合并带来的代码冲突和基础的质量风险。
• 典型行为：冲突检查、代码编译、单元测试、代码规范检查（如 ESLint）、代码合并。

2. CD（持续交付和或持续部署）

    CD指的是持续交付（Continuous Delivery）和或持续部署（Continuous Deployment）。

2.1 持续交付

    在持续集成（CI）的基础上，为了确保软件能够随时发布到生产环境，引入了持续交付。

• 核心目标
• • 确保软件始终处于可发布状态，能够快速、可靠地发布新版本；
• • 强调软件的可发布性，允许业务团队灵活控制发布时间。
• 典型行为
• • 自动化构建、测试和打包代码；
• • 将代码部署到类生产环境（例如预发布环境）进行测试（自动化+人工）；
• • 提供人工控制的发布流程，可以在类生产环境测试ok后，人工灵活控制发布时间。

2.2 持续部署

• 核心目标
• • 实现完全自动化的软件发布流程，将在类生产环境下通过测试的代码更改自动部署到生产环境；
• • 追求快速反馈循环，尽快将新功能交付给用户。
• 典型行为：
• • 自动化构建、测试和打包代码；
• • 将代码部署到类生产环境（例如预发布环境）进行测试（自动化+人工）；
• • 在通过所有测试后，自动将产物发布到生产环境。

2.3 持续交付和持续部署的区别小结

    持续交付和持续部署的主要区别发生在“部署到类生产环境”之后；持续交付需要人工批准，而持续部署则完全自动化；简单来说，在经过自动化测试和类生产环境测试后，持续交付需要人工点击“部署到生产环境”的按钮，而持续部署是自动进行这个步骤。

二、CI/CD典型流程与技术原理

2.1 CI/CD 基本流程

代码提交 → 触发构建 → 测试 → 产物输出 →产物发布/部署 → 监控反馈

2.2 概念解析与基本原理

    代码提交：开发者推送代码至 Git 仓库（如 GitHub、GitLab、公司自己仓库、个人仓库等）。

    触发构建：代码仓库收到代码合并请求， 会主动推送变更通知 到CI 服务器（如 Jenkins）触发代码检查、构建等流程。
     比如，在android工程持续构建中，代码检查、编译、clean、单测等任务（Task）都是我们自己工程中通过gradle定义的，这些Task可以通过.sh脚本调用，而.sh(shell脚本)保存成一个文件后，在系统范围内通过sh 命令都可以调用这个脚本文件来执行这些任务，sh脚本是打通 系统调用和我们gradle命令的通道。这样当CI服务收到代码变更的通知后，便开始通过sh命令来调用一个我们工程中定义的task执行各种检查、编译、单测等任务。

    测试验证：主要包括各种质量和安全测试，比如单元测试（覆盖函数逻辑）、集成测试（验证模块交互）、安全扫描（如 SonarQube）等

    产物输出：输出APK、容器镜像（Docker）或二进制文件等。

    产物发布/部署：对于客户端应用就是将产物发布到线上环境，如各个应用商店，用户下载更新包后安装到本地运行；对于前端或者服务端应用则是把产物推送到服务器上，并运行起来

三、CI/CD 的核心目标与价值

    1. 减小集成风险：通过高频测试和快速反馈，将问题变的小，且拦截在开发阶段，避免累积至发布前夕

    2. 加速交付效率：自动化流水线替代人工操作，缩短从代码提交到用户可用的周期（如从数周缩短至小时级）；

    3. 提升代码质量：强制代码规范检查、测试覆盖率要求，减少低级错误流入生产环境。

四、CI/CD 的本质

    CI/CD 系统本质运行在服务器上的应用程序，这些程序持续监控代码仓库的变化，当检测到新的代码提交（push）或合并（merge）时，它们会自动触发预定义的流程。

    CI/CD 系统通常提供一个网页界面，用于配置 CI/CD 流程，查看构建和部署的状态，查看日志和报告，手动触发某些操作（例如，重新运行构建）等，网页界面只是一个控制中心，实际的构建、测试和部署工作都是在服务器上执行的。