v6ole
132 lines
8.1 KiB
Markdown
132 lines
8.1 KiB
Markdown
# 中国电信软件研发规范流水线管理分册（修订版）
|
|
|
|
> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
|
|
|
|
中国电信软件研发规范流水线管理分册 （修订版）
|
|
|
|
中国电信集团有限公司
|
|
|
|
## 2023 年 12 月
|
|
|
|
> 编制人员信息已移除。
|
|
|
|
版本变更历史
|
|
|
|
## 1 文档说明
|
|
|
|
### 1.1 编制说明
|
|
|
|
为进一步提升全集团的流水线使用水平， 实现持续集成 、持续部署， 集团编制了软件研发规范—流水线分册， 用于指导和规范全集团研发人员使用流水线， 实现持续集成 、持续部署的能力。
|
|
|
|
### 1.2 文档结构
|
|
|
|
本规范由文档说明 、项目过程中使用流水线的适用原则 、流水线执行的动作要求构成， 各章节的主要内容如下：第 1 章文档说明， 对编制目的 、文档结构 、使用范围 、起草单位 、解释权、版权和本规范用到的术语进行了说明。第 2 章项目过程中使用流水线的适用原则， 对流水线使用原则 、流水线命名规范 、步骤命名规范 、流水线触发类型分类进行了说明。第 3 章流水线执行的动作， 对流水线执行动作的种类 、流水线执行动作内容推荐及流水线执行动作要求进行了说明。
|
|
|
|
### 1.3 适用范围
|
|
|
|
本规范适用于指导中国电信软件研发工作。
|
|
|
|
### 1.4 起草单位
|
|
|
|
本规范的起草单位是中国电信集团公司。
|
|
|
|
### 1.5 解释权
|
|
|
|
本规范解释权属于中国电信集团公司。
|
|
|
|
### 1.6 版权
|
|
|
|
本规范的版权属于中国电信集团公司。
|
|
|
|
### 1.7 名词解释
|
|
|
|
## 2 项目过程中使用流水线的适用原则
|
|
|
|
### 2.1 流水线配置要求
|
|
|
|
流水线的信息， 需按照以下规范进行配置：l 流水线必须属于单个项目组， 不允许跨项目使用流水线；l 流水线的命名要求做到简洁明了， 以便度量考核。
|
|
|
|
#### 2.1.1 流水线命名规范
|
|
|
|
流水线应当由英文小写字母（a-z） 、数字（0-9） 、 中划线（-） 组成， 且第一个字符仅允许使用字母。流水线名称不可使用“test ”、“demo ”等意义不明的字样， 可以使用{业务名称}-{模块名称}-{语言}这种名字标识 。通过流水线名字， 可以快速确认流水线用途。示例： “srdcloud-usercenter-java ”
|
|
|
|
#### 2.1.2 步骤命名规范
|
|
|
|
步骤名称可以由小写字母（a-z） 、数字（0-9） 、 中文组成。步骤名称不可使用“test ”、“demo ”等意义不明的字样 。应该根据每个步骤的具体用途作为步骤命名。示例： “Maven 构建 ”、“质量扫描 ”、“Java-Build ”
|
|
|
|
#### 2.1.3 流水线运行环境要求
|
|
|
|
流水线上运行的构建等步骤的执行环境必须和开发环境保持一致。
|
|
|
|
### 2.2 流水线的触发类型
|
|
|
|
流水线的触发类型定义为以下几种：
|
|
|
|
1.手工触发——指开发人员登录集成工具手动触发流水线2.定时触发——指流水线由一个定时规则进行触发3.事件触发——指流水线由代码库或制品库的一些动作 、事件触发， 这些动作 、事件主要包括以下几种：
|
|
|
|
### 2.3 项目过程
|
|
|
|
项目过程中， 根据项目组选取不同的开发模式以及测试 、部署模式， 需要按照要求配置流水线。
|
|
|
|
#### 2.3.1 代码评审流程
|
|
|
|
项目开发过程中， 若项目组启用代码评审流程， 需要根据评审流程设置VerifyCI 流水线以及 MergeCI 流水线至少两条流水线。其中 VerifyCI 流水线与的触发类型需使用“代码提交评审 ”事件， MergeCI流水线的触发类型需使用“代码合入 ”事件。
|
|
|
|
#### 2.3.2 不启用代码评审流程
|
|
|
|
项目开发过程中， 若项目组不启用代码评审流程， 需要设置至少一条流水线 。其中该流水线的触发类型需使用“代码更新 ”事件。
|
|
|
|
#### 2.3.3 测试过程
|
|
|
|
项目测试过程中， 项目组需设置至少一条流水线触发测试任务， 触发类型可按需选择。
|
|
|
|
#### 2.3.4 部署过程
|
|
|
|
项目部署过程中， 项目组需设置至少一条流水线触发部署任务， 触发类型可按需选择。
|
|
|
|
## 3 流水线执行的动作要求
|
|
|
|
### 3.1 流水线整体流程图
|
|
|
|
### 3.2 流水线包含的内容
|
|
|
|
#### 3.2.1 持续集成
|
|
|
|
1. 获取代码： 流水线的基础单元就是对代码进行才做， 因此流水线要对代码库具有下载的权限。2. 单元测试： 单元测试是开发者编写的一小段代码， 用于检验被测代码的一个很小的 、很明确的功能是否正确 。单元测试的实现方式包括： 人工静态检查 、动态执行跟踪两种。3. 代码检查（质量扫描）： 包括代码安全扫描和代码质量扫描 。代码安全扫描检查源代码缺陷是否会造成安全漏洞问题， 而代码质量扫描检查编码是否存在违规。4. 编译构建： 编译构建是指把软件的源代码编译成目标文件,并把配置文件和资源文件等打包的过程。
|
|
|
|
5. 制品构建： 制品可能是一个包 、一个二进制文件或者一个 docker 镜像 。制品构建就是将编译构建的产出物制作成最终程序能够运行的文件过程。6. 上传制品： 将制品构建的制品上传到统一制品库中进行集中管理。
|
|
|
|
#### 3.2.2 持续交付
|
|
|
|
1. 执行测试用例： 可调用“测试管理 ”分册的测试任务能力， 或将一些比较复杂或者可以通过自动化脚本执行的用例通过接口进行调用， 可以自动完成某些测试 。大大节省测试人员的时间成本。2. 部署测试环境： 测试用例完成后， 可以将制品自动化部署到测试环境 。详细可见“部署 ”分册。3. 测试环境测试： 测试人员在测试环境进行用例测试 。如果发现测试 bug，要及时反馈给开发人员 。待开发人员修改完成并通过执行测试用例后， 测试人员再次进行测试。4. 部署预生产环境： 预生产环境和生产系统的同步性更高， 几乎一样 。有些测试， 比如需要大数据量的， 用预生产环境看程序性能比用测试环境（一般情况下数据会较少） 会更准确。5. 预生产环境测试： 在预生产环境中进行测试通过后， 准备部署正式生产环境。
|
|
|
|
#### 3.2.3 持续部署
|
|
|
|
1. 灰度发布： 是值一种平滑过渡的发布方式 。灰度发布可以保证整体系统的稳定， 在初始灰度的时候就可以发现 、调整问题， 以减少其影响度。2. 卡点检查： 通常是以集群方式进行部署 。发布后要在部署的集群进行人工检查或者 api 调用等方式对服务验证和测试 。经过验证通过后， 才能进行下一个集群的部署更新。
|
|
|
|
### 3.3 流水线内容推荐
|
|
|
|
项目过程中会配置多条 、多种用途的流水线 。本小节会根据流水线的用途、
|
|
|
|
所在的分支 、项目所采用的开发流程等因素， 推荐该条流水线需要包括的内容。本小节内容非强制要求。
|
|
|
|
#### 3.3.1 VerifyCI 流水线
|
|
|
|
VerifyCI 流水线与代码评审流程有关， 在“代码提交评审 ”时触发。VerifyCI 流水线的作用一般是检查本次提交的代码是否可以正常构建， 执行代码的单元测试以及使用 SonarQube 工具进行代码扫描生成质量报告。
|
|
|
|
#### 3.3.2 MergeCI 流水线
|
|
|
|
MergeCI 流水线与代码评审流程有关， 在“代码合入 ”时触发 。MergeCI 流水线的作用一般是对本次代码进行构建， 并将构建产物推送至制品库。
|
|
|
|
#### 3.3.3 ReleaseCI 流水线
|
|
|
|
ReleaseCI 流水线， 一般会由代码库的 release 分支的“代码更新 ”事件自动触发， 这条流水线的作用一般用于对代码进行安全漏洞扫描。
|
|
|
|
#### 3.3.4 测试任务流水线
|
|
|
|
测试任务流水线， 可以对代码库的某个分支的“代码更新 ”事件自动触发，该条流水线执行自动测试任务。
|
|
|
|
### 3.4 按能力等级划分流水线内容要求
|
|
|
|
在项目过程中， 整体项目的流水线需具备以下内容（如某条流水线包括“制品上传 ”内容， 则视为该项目具有“制品上传 ”的内容）， 见下表（其中○代表可选， ●代表必选）
|