xmlns="http://www.w3.org/2000/svg">

d="M5,0

style="-webkit-tap-highlight-color:

rgba(0,

0)">

引言：流水线跑不稳？

因为没抓牢

“原则”

的困境：

• 明明配了自动化，却还要手动点编译、手动传包；
• 代码出问题了，要半天才能定位到是哪次提交、哪个版本的锅；
• 环境不一致；就是测试环境跑的好好的，到生产就报错，排查了才发现
• 一堆

  jar

  包、镜像文件杂乱无章，想回滚版本都找不到对应的包。

  
  其实，这些问题的根源就两个：没吃透

  CI/CD

  大核心原则（自动化、高效反馈、可追溯、环境一致性），讲清每个原则的落地要求；再详解制品的定义、作用和存储方式，帮你搭建

  “原则指导

  的稳定流水线，内容可直接复用在学习和工作中。

核心原则详解：4

每个原则都对应着明确的落地要求，遵守则流水线顺畅，违反则困难不断。

就是CI/CD

1：自动化

“灵魂”，告别手动重复劳动

核心定义
用工具替代所有可重复的人工操作，让流水线从

“代码提交”

的全流程，无需人工干预就能自动运行。

• 反例：代码提交后手动点

  “构建”、测试通过后手动传包、生产部署时手动敲命令；

• 正例：代码提交自动触发构建→自动测试→自动打包→自动部署，全程无人值守。

  
  落地要求（必须满足

  id="1_16">1、‘’全流程自动化，无断点

• 覆盖

  全环节，不遗漏任何一个重复步骤；

• 关键节点（如测试失败、部署异常）自动触发告警，而非人工巡检。

2、自动化操作标准化，可复用

• 所有自动化步骤都通过

  “脚本

  项目、前端计划）复用同一套自动化脚本，避免重复造轮子。

“带病流转”

• 任意环节失败（如构建失败、单元测试不通过），流水线立即终止，不允许进入下一环节；
• 失败原因自动记录并推送（如邮件、企业微信），方便相关人员快速定位。

原则

2：快速反馈

难题早发现，早解决，降低返工成本

核心定义
流水线每个环节达成后，立即反馈结果，让问题在

暴露，避免问题流入后续环节（尤其是生产环境）。

• 反例：代码合并后过了

  天才构建，发现冲突；测试通过后部署到生产才发现功能异常；

• 正例：代码提交后

  分钟内完成冒烟测试，异常立即回滚。

  
  落地要求（必须满足

  id="1__32">1、反馈速度要

  分钟内（超过需优化，如缓存依赖、并行测试）；

• 集成测试、部署验证的耗时控制在

  分钟内，避免流水线

  “卡半天”。

2、反馈内容要

空指针异常，提交人：张三”；

避免模糊反馈，如

id="3__38">3、反馈渠道要

“直达”，精准推送责任人

• 问题直接推送给

  “相关人员”，而非

  “全员群发”：代码冲突推送给提交人，测试失败推送给构建，部署异常推送给运维；

• 协助多渠道推送（邮件、企业微信、钉钉），确保信息不遗漏。

原则

每一个版本，都能

“查得清、找得到”

核心定义
流水线的每一个环节、每一个产物都有唯一标识和完整记录，确保任何时候都能追溯

“这个版本是谁提交的、什么时候构建的、测试结果如何、部署到了哪个环境”。

• 反例：线上出问题了，找不到对应的代码版本；测试通过的包和生产部署的包不是同一个；
• 正例：线上故障→查部署记录→找到制品版本→关联代码提交

  ID→定位问题代码→回滚到上一版本，全程

  v1.0.1、v1.0.2-fix）；

• 标识之间要关联：制品版本

  v1.0.1

  abcdefg。

2、所有操作都有

“张三

“一键回滚”，追溯不是目的，可回滚才是

任何版本的制品都要保留，回滚时只需指定版本号，无需重新构建；

回滚操作也要记录日志，明确

“谁在什么时候回滚到了哪个版本”。

id="_4_____58">原则

的终极方案

核心定义
开发、测试、预发布、生产环境的配置、依赖、运行环境完全一致，避免因环境差异导致的

JDK11，测试用

容器化部署”，开发、测试、生产用同一个镜像，仅经过配置文件区分环境。

落地要求（必须满足

点）

1、环境

“标准化”，用容器化

虚拟机封装

• 创建、测试、生产环境使用相同的基础镜像（如

  Java

  Dockerfile、requirements.txt）定义。

• 配置

  “分离化”，环境变量区分不同环境

id="2_68">2、代码和调整分离：代码中不写死配置（如数据库密码、接口地址），而是经过环境变量注入；

• 不同环境使用不同的配置文件：开发用

  dev.yaml，测试用

  “隔离化”，避免相互干扰

• 编写、测试、生产环境物理隔离或逻辑隔离（如

  K8s

  创建临时数据库）。

4大核心原则落地要求总表

alt="在这里插入图片描述"

src="https://i-blog.csdnimg.cn/direct/bb044bfe09dc40ff8a9f3d97693ea752.png">

核心产物：制品

“标准化、可部署、可运行的软件包”。

就是制品

• 通俗理解：制品就是

  “原材料→加工→成品”

  “成品”；

• 关键特征：可重复部署、与环境无关、版本唯一、可追溯。

id="2__83">2.

的封装体，同一个制品在任何环境下运行的结果都是一致的，从根源上消除

“测试能跑，生产报错”

“唯一标识”

每个制品都有唯一的版本号，关联着代码提交

ID、构建记录、测试报告，出问题时能飞快定位到对应的版本，建立一键回滚。

（3）提升部署效率的

“预编译、预测试”

的成品，部署时无需再编译、测试，直接拉取制品运行即可，部署时间从

“小时级”

src="https://i-blog.csdnimg.cn/direct/8396cf5e17b548d895c4b53715ba689c.png">

4.

“专属仓库”

制品不能随意存在服务器上或本地电脑里，必须存储在专用的制品库中，这是制品管理的核心。

id="1_96">（1）常见的制品库器具

alt="在这里插入图片描述"

src="https://i-blog.csdnimg.cn/direct/5bcc0e48176b4fcbaabfd2ff39315236.png">

（2）制品存储的核心规范（必须遵守）

id="1_100">1、分类存储，结构清晰

按

“项目名称

组织目录，比如test-project/v1.0.1/test-1.0.1.jar；
禁止不同工程、不同版本的制品混存。

2、权限控制，安全第一

开发人员：可读可写（上传自己任务的制品）；
测试人员：可读（拉取制品部署测试环境）；
运维人员：可读（拉取制品部署生产环境）；
禁止

id="3_108">3、清理策略，节约空间

保留最近

个月的制品和所有生产环境利用过的制品；
自动清理过期的测试版本、废弃版本（如-beta版本）。

三、核心原则

alt="在这里插入图片描述"

src="https://i-blog.csdnimg.cn/direct/e6bd391d37354a749e401607bbc07677.png">

核心原则和制品管理不是孤立的，而是相互联动、相互支撑的，举一个完整的联动场景：
1、自动化：代码提交后，自动构建→测试→打包成制品→推送到

Harbor；
2、快速反馈：打包失败立即通知开发，制品推送成功后通知测试；
3、可追溯：制品

v1.0.1

ELK；
4、环境一致性：测试和生产环境都拉取同一个镜像harbor.xxx.com/test-project/test:v1.0.1，仅依据环境变量区分调整；
5、出问题时：依据制品版本

v1.0.1

v1.0.2→一键回滚生产环境，全程可追溯、无环境差异。

id="_121">四、总结：原则是指导，制品是核心，两者结合才是王道

1、4

CI/CD

自动化减少人工错误，高效反馈降低返工成本，可追溯支持问题定位，环境一致性消除诡异故障；
连接

“代码”

管好制品，才能实现版本可控、部署高效、环境一致；就是2、制品是

CI/CD

入手，再逐步完善快速反馈、可追溯、环境一致性的能力，小步快跑，逐步优化。