2024年4月10日发(作者：cdrx4安装包)

DevOps版本发布管理规范

1. 范围

本流程是为了指导和规范DevOps开发模式的产品在发布阶段的活动，确保版本发布活动有序开展，

高效执行支撑产品快速上线发布。

2. 版本命名规则

公司Release命名规则有两种模式，一种是点分模式，一种是VRC模式。两种命名

模式在公司级的系统中均能应用，为避免模式多次切换引起客户界面的混乱，产品一旦

采用了点分模式，就不允许再切换回VRC模式。点分模式是未来的发展方向，建议新业

务模式/新产品采用点分模式。详细命名规则如下：

1) 点分模式：

字段

类型

简称

字符

限制

长度

承载

内容

大版本号

(Major)

X

纯数字

1~4位

小版本号

(Minor)

.Y

纯数字

1~4位

发布号

(Release)

.Z

由字母、数字和中线

组成

1~14位

承载发布的顺序号

特性集 特性子集

以及需要显式表达

的属性

Bug修复 内部调测序号

补丁

(Patch)

.P

由字母和数字组成

1~8位

内部调测

(Build)

[.Bxxx]

由字母和数字

组成

4位

需要区分补丁类型的产xxx从001开始

编 号

1.原则上从1开

Y从0开始以1

模式由两部分构成： 1.

始以1为单位递

为单位递增。

1. 序列号+[‘-’+品：以1为单位递

增，需对接开源扩展属性标识]; (SPCx/SPHx/CPx/HPx）; 增编号；

社区的可以从0

开始编号；

2.产品线可以根

据需要采用年

份、协议版本号

等。

2. 序列号包括：x，2. 无需区分补丁类型的产

RCx，Tx，序列号

3. 扩展标识包括：

Lxxxyy，PWE，

Clean，扩展标识

品直接采用x表示。

单位递增。

之间独立编号； 3. x从1开始递增以1为

之间采用‘-’隔

开

编 号

当版本发生了重

升 级

大的特性或者架

构变更时，大版

规 则

本号需要升级；

“重大”的含义

由产品线根据自

身业务特点自行

决定。

举 例

1) 2.0.0

2) 1

3) 2.0.T1

4) 2.0.0.1

为快速响应客每一次发布Update每次发布一个补丁或者补

每一次全编译

户需求，分步骤版本，发布序列号x丁集合，补丁编号x加1

转测试，编号

实现大版本号增加1。

加1

规划的特性集，

每个小版本号

实现一个特性

子集；

.B001

5) 1

6) 1

7) 1

2) VRC模式：

字段

类型

简

称

大Release 小Release 分支Release 补丁 非商用 Build

Vxxx Rxxx Cxy [Lxxxyy]

[SPCxxx/SPHxxx

CPxxxx/HPxxxx]

[T] [Bxxy]

承

载

内

容

平台集版本，特性集版

产品基于的本，面向客

软件或者硬户发布的

件平台版本 特性集合

0表示功能增强定制版本

性小版本/修复缺陷

的维护版本；

为分支版本

仅缺陷修复&改非商用内部转测

错，禁止新增特性 版本 试版本，

禁止对客

户呈现

1. V版本号和R版本号独1. 在同一R版本下，C版本从C001. 补丁的含义可

立编号，互不影响； 开始按规则变化，R版本号变参考6.2.5的

2. V版本的xxx从100开化，Cxx从C00开始重新编号，内容；

始以100为单位递增C00代表R版本； 2. SPC/SPH的顺

编号； 2. 标识功能增强性的通用小版本/序号xxx从

编

3. R版本的xxx从001开修复缺陷的维护版本时用Cx0，001到999以1

号

始以1为单位递增编x为0-9，C00、C10、C20依次为单位递增编

规

号。 递增； 号；

则

3. 标识分支版本时用Cxy，y≠0，3. CP/HP的顺序

如从C00上切出的分支版本为号xxxx从

C01、C02。 0001到9999

4. L版本规则可参考6.2.4的内容 以1为单位递

增编号。

1) V100R001C00

2) V100R001C00LIN101

3) V100R001C00SPC001

4) V100R001C00CP0001

5) V100R001C00LIN101SPC001

6) V100R001C00T

7) V100R001C00LIN101SPH001T

标识非

商用版

本，后

面不带

任何字

母。

B版本的

顺序号

xxy可参

考新规则

中的编号

建议

举

例

B001

3. 版本发布质量要求

3.1. 服务上类生产的入口要求

1、代码100% Review （代码已经过结对Partner的Review，但关键代码需经过

MDE等专家Review。如果未采用结对编程实践，则代码须经过正式Review。）

2、代码通过静态检查工具检测且告警清零（代码通过PClint、Findbugs静态检查

工具的检测，日清日结。CodeCC（含Coverity/Fortify）工具由于执行时间较长，按迭

代清零。）

3、新增代码通过LLT测试且自动化测试用例合入CI，代码覆盖率满足目标要求

（LLT为开发人员的测试活动，是针对特性/Story的开发自验证，用例执行速度快；分

支覆盖率>80% ）

4、功能测试用例密度满足目标并100%执行，自动化用例合入CI（必须是在真实的

测试环境上测试通过。 ）

5、迭代问题解决率达到85%，无遗留致命问题（问题解决的标准是代码修改完成，

合入配置库，回归测试通过。）

6、交付文档及资料，100%经过评审及验证 （ 操作文档100%经过验证 、介绍说

明文档100%经过评审）

7、遗留问题风险分析通过

8、版本经过“开源及第三方软件”扫描，漏洞及法务风险评估通过

9、对外发布版本经过安全测试，安全风险评估通过

3.2. 版本发布要求

1、 所有版本发布必须经过如下验证和评审活动，不能缺失。设计开发测试——服

务集成测试——解决方案集成验收——商用——全球发布评审（全球发布）。

2、解决方案版本发布评审之前各服务需按照附件《发布评审要素》进行自检，如

不满足，不能提交解决方案发布评审。

3、评审专家要代表本领域表达评审意见，评审专家要全员出席发布评审会议，如

缺席必须要提前给出评审意见或委托可以代表本领域的人参加评审会议，所有评审专家

达成一致才能形成同意发布的决议。

4、商用发布的版本建议经过商用验证。对于新服务和特性需经过统一审视，由组

织决策哪些新服务和特性必须经过更长的（如3个月）商用验证后才能发布。

5、全球版本发布后，由全球各局点项目团队负责规划现网升级策略和执行版本匹

配升级。

4. 版本发布通道

通过公司布流程向下游传递版本，严禁研发人员直接向下游传递版本。严禁传递或

使用未经发布的“非法版本”。

5. 产品/服务资料发布

资料发布是产品交付件发布活动之一，是一个确认资料满足质量标准，保证版本资

料齐套、完整，并快速、准确、高效地传递给下游用户的过程。资料分类包含：

➢ 产品文档：面向企业用户或租户交付的产品描述类文档。

➢ 维护文档：随版本输出，面向技术支持工程师及运维人员交付的产品售后技术

支持文档。

➢ 版本配套文档：描述版本变更点的相关文档，按照版本粒度输出。