从“没有CI/CD团队”进化到“使用CI/CD基础设施的团队，再到“使用AI基础设施的团队”

没有 CI/CD 的团队

1. 项目创建
2. 功能编写
3. 代码提交
4. 功能自测
5. 代码 Review
6. 合并发布分支
7. 人工构建
8. 人工部署
9. 产品发布
10. 人工观察线上质量
11. 质量修复、持续改进（循环第3步开始的内容）

上面是一个常规的单任务场景下的流程，可以看到起码有10个步骤：当然有的公司会省略一些步骤，诸如Code Review；也有许多人只会接触到功能编写和提交代码几个阶段。

实际场景中，会更复杂一些，涉及“并行开发多个需求”、“多个完成的功能等待上线”、“部分代码进行重构，等待兼容测试”等等。

整个研发流程会浪费非常多的资源：聪明能干的工程师总是不停的做着构建、发布、大量非必要的线上人肉观察等本该机器做的事情。

有部分自动化脚本的团队

1. 项目创建
2. 功能编写
3. 代码提交
4. 功能自测
5. 代码 Review [这里可能使用了一些lint、coverage、risk scanner功能分摊了一些Review压力]
6. 合并发布分支 [这里可能使用了一些脚本进行对非敏感内容进行自动合并]
7. 人工构建 [有抽象构建过程为脚本，然后通过手工调用]
8. 人工部署 [有抽象部署过程为脚本，然后通过手工调用]
9. 产品发布 [有抽象发布过程为脚本，然后通过手工调用]
10. 人工观察线上质量 [有编写一些监控程序，然后通过手工调用]
11. 质量修复、持续改进（循环第3步开始的内容）

可以看到在流程没有任何变化的过程中，因为多了一些工具的引入、过程脚本的编写，很多事情可以让机器去做了，这样可以解放一大部分重复简单工作上的资源。

但是，协调每个阶段的事情，多数是由人来做的，因为有人的介入，部分自动化的事情，变的有一些不可控和不可靠，人是情绪化的动物，总会有疲惫、松懈的状态出现，然后可能影响到结果。

人工进行诸如:

• maven build
• npm build
• docker build

然后执行 maven、npm、docker push 真的是有意义的吗？

而这个过程经过统计，其实在软件开发过程中占比并不会很低。而且在多数时候，这些定制化的辅助脚本各式各样，后续一旦想批量进行升级更换操作，十分麻烦，缺乏标准化的技术方案，是应该被摒弃的。

使用 CI/CD 基础设施的团队

1. 项目创建
2. 功能编写
3. 代码提交 [CI工具介入]
4. 功能自测
5. 代码 Review [CI工具介入]
6. 合并发布分支 [CI工具介入]
7. 人工构建 [CI工具介入]
8. 人工部署 [CD工具介入]
9. 产品发布 [CI/CD工具介入]
10. 人工观察线上质量 [CI工具介入]
11. 质量修复、持续改进（循环第3步开始的内容）

看起来和上面并没有太大的不同，确实是这样：如果你的研发流程是正常的，CI/CD并不改造你的研发流程，只是给你进行标准化的工程流水线改造。

以 GitLab + GitLab CI Runner 环境下的CI/CD为例：

• 在代码提交之后，将会根据提交分支进行不同的自动化处理：
  • 代码常规检查
  • 自动化单元测试
  • 依赖漏洞检查
• 在代码 Review 阶段，因为上一阶段已经进行了 Code Style、代码底层实现 Code Lint等检查，相关reviewer只需要对逻辑和实现方案进行Review。
• 在合并发布分支阶段，可以自动检查是否冲突，如果没有冲突自动进行合并，有则进行通知，等待人工介入，人工只做必须介入的事情。
• 在构建过程，CI可基于标准的容器镜像进行构建，依赖被约束在稳定的镜像二进制包内，唯一的变量就是你有变动的代码，保障构建环境是可准确、可靠、可迁移的。因为使用 dockerfile 进行描述，容器环境的分析和升级也变的透明、可追溯。在构建结束将成功与否的结果告知工程师，但仅仅是告知即可，因为软件已经可以到下一个阶段进行自动化部署了。
• 在部署阶段，CI可基于上一步构建结果是否正确进行下一步的分发操作，包括交付测试使用的测试环境、给开发自行联调使用的开发环境、给团队成员验收使用的预发或者叫仿真环境、乃至线上正式的生产环境。
• 最后，当部署完成之后，等待人工介入完成产品上线切换，会触发CI的线上复查、监控验收。

可以看到虽然之前看似简单的过程脚本变成了一大块的持续集成执行阶段，但是带来了容器标准化执行，未来对构建环境的统一维护和升级可以快速被应用。以前手动执行的任务既简单又耗资源，现在通过自动化处理后，很多流程在后台自动运行，只有需要人为决策时才需人工介入。这样不仅为研发团队节省了大量资源，也减少了工程师在软件开发过程中遇到的等待和中断。

使用AI基础设施的团队

工程理念的升维：从“构建”到“培育”（从 “追求确定性”到“拥抱不确定性”）

传统理念核心是构建（Build），像建造大楼一样，根据精确的蓝图（需求规格），用标准化的构件（代码库、API）搭建出一个功能确定的系统。工程体系的目标是保证建造过程的高效、合规和高质量。

AI时代，大模型提供了土壤（知识库）、养分（数据）和引导（Prompt），并持续观察、修剪、调整，使其朝着我们期望的方向“生长”，建立有效的观察和干预机制。

工程实践的进化

持续集成/持续交付（CI/CD）流水线是DevOps的核心，它将代码的提交-构建-测试-部署自动化，追求的是交付速度和可靠性。

借助于平台工程和大模型能力，需要引入一个全新的核心循环：实验-评估-调整（Experiment-Evaluate-Adjust）。

• 实验（Experiment）： 快速尝试不同的模型、Prompt策略、RAG配置等。
• 评估（Evaluate）： 建立新的评估体系，不仅看性能，更要度量结果的准确性、安全性、成本和用户满意度。
• 调整（Adjust）： 根据评估结果，快速调整Prompt、优化知识库或进行模型微调，形成一个持续学习和优化的闭环。