部署流水线相关的规范性定义

软件的每一次变更都会经历一个复杂的质量验证流程，验证合格后方可发布，这一流程包括软件的构建以及后续的一系列的测试和部署，而部署流水线是对这一过程的可视化模型。即：“部署流水线”是指“软件从版本控制库到用户手中”这一过程中所有环节的可视化展现形式。

每一次代码变更都被视为一个达到交付质量的潜在可交付产品。理想情况下，每当一个ChangeList（简称CL）进入到代码仓库，部署流水线就会被其自动触发开始执行，并在无人干预的前提下。前一环节成功通过后，自动触发下一环节的质量检验，直至最后成功通过，并部署到生产环境（或交到用户手中）。

在满足产品代码质量检查（如执行时间短/质量反馈佳）的前提下，部署流水线越简单，环节越少越好。更详细的设计原则请参见《持续交付2.0》第7章 7.2节 “部署流水线的设计与使用”。

以下为单一代码仓库就是一个交付单元的情况。例如：一个微服务就是一个交付单元；一个App客户端也是一个交付单元；一个提供给其他团队使用的SDK也是一个交付单元。

现代代码版本控制软件（如GIT，SVN）都提供通过创建分支实现暂时隔离开发者之前相互干扰的能力。

代码分支模型在一定程度上反映了团队成员之间的合作模式与合作状态，也是团队整体软件研发能力的一种体现。

对于一个需要多次交付的软件产品来说，分支越多，会令“从代码提交到产品上线”这一过程的协作流程越长，部署流水线越复杂。

若分支模型中存在多种类型的分支，且每类分支担当不同隔离职责，其软件产品的部署流水线越复杂。

因此，一个软件产品（交付物）的完整部署流水线可能是由多级部署子流水线互相衔接（串行或并行）而成。子流水线的多少与复杂程度与产品团队所采用的分支模型强相关。

每一条分支都应该有一条相对应的部署流水线，除非该分支已没有代码提交。

不同级别的分支对该分支上的代码质量要求可能也有所不同。

每一条分支所对应的部署流水线，流水线中不同阶段所需执行的质量检查任务有应用不受外界干扰的验证环境。

例如：

• 单人独占的个人开发分支通常需要个人手工调试环境和自动化开发验证环境；

• 团队共享代码的团队分支对应的需要不同维度和不同种类的测试验证环境；如自动化单元测试和接口测试运行的自动化测试验证环境。

• 产品主干分支对应的则需要相应的自动化测试验证环境和UAT环境。

• 产品发布分支对应的实际生产环境。

• 以上示例并不完备，需根据实际的分支模型相匹配。

理想情况下，每一条分支上有代码变更时，都应该自动触发其对应的部署流水线，进行该分支所要求的质量验证活动。

说明：理想情况是指每次触发部署流水线的执行，其验证执行活动的时长足够短。
关于缩短执行时间的方法，以及部署流水线的权衡原则参见《持续交付2.0》第7章 7.2.1节 “部署流水线的设计原则”。

关于产品代码库的分支模式设计，请参见《持续交付2.0》 第8章 “利于集成的分支策略”。

4.1 关于部署流水线级别的通用规范：

1）按照常见分支类型分类，部署流水线有以下几种：

为方便区分，需在流水线label新建标签名为type的标识，type常见的值有RELEASE(日常版本发布类) / PRE_RELEASE(预发布环境部署类) / HOTFIX(补丁发布类) / MASTER（主干类） / SHARE(多人共享分支类)。

常规流水线（或日常流水线）：是指该软件产品团队日常工作中都比较关注的主要流水线。

• 产品发布分支的常规流水线：

• 如果该分支长期存在，并且持续有代码合入，应该有对应的一条日常部署流水线。

• 该流水线在持续集成平台上定义Label 为“type=RELEASE”，前后无空格，全部大写英文字母。

• 产品预发布环境部署发布流水线：

• 项目需要具备针对主干和多人共享分支（若有）按照一定的间隔持续将对应分支代码功能部署至预发布环境进行及时验证。

• 该流水线在持续集成平台上定义Label 为“type=PRE_RELEASE”，前后无空格，全部大写英文字母。

• 产品补丁发布流水线：

• 若项目存在补丁发布，则需要配置补丁发布流水线，用于版本补丁发布。

• 该流水线在持续集成平台上定义Label 为“type=HOTFIX”，前后无空格，全部大写英文字母。

• 主干(master)分支的常规流水线：

• 至少有对应的一条部署流水线。

• 该流水线在持续集成平台上定义Label 为“type=MASTER”，前后无空格，全部大写英文字母。

  按触发方式主干分支常见流水线有：提交构建。

• 多人共享分支的常规流水线：

• 至少有对应的一条部署流水线。

• 该流水线在持续集成平台上定义Label 为“type=SHARE”，前后无空格，全部大写英文字母。

2）按照常见触发方式，部署流水线针对主干和多人共享分支又可细分出以下几种类型：

• 为方便区分，需在流水线label新建标签名为category的标识，category常见的值有MAIN(提交构建)/SECONDARY(次级构建)/INTERVAL(定时构建)。

• 主干/多人共享分支定时流水线：通常是作为日常流水线的质量补充验证，执行时间比较长的质量验证任务，触发模式通常被定义为“每天或每隔N小时”定时构建。

• 例如，全量的Coverity扫描，全量的性能测试。

• 自动化测试稳定性检测流水线：主要用于输出评估团队自动化测试稳定性指标。其category对应的值为RELIABILITY（稳定性）。

• 自动化测试稳定性指标解读，请参考07.auto-testing.md中的“管控并持续修正不稳定的测试用例，单元测试与自动化测试的稳定性满足各level要求”。

3）流水线在持续集成平台上定义Label定义组合为： 

• 主干定时流水线标签标识：“type=MASTER” “category=INTERVAL”  。

• 多人共享分支定时流水线标签标识：“type=SHARE” “category=INTERVAL”  。

• 主干提交构建流水线标签标识：“type=MASTER” “category=MAIN”  。

• 多人共享分支提交构建流水线标签标识：“type=SHARE” “category=MAIN” 。

• 主干次级构建流水线标签标识：“type=MASTER”“category=SECONDARY”  。

• 多人共享分支次级构建流水线标签标识：“type=SHARE” “category=SECONDARY”  。

• 主干预发布环境部署类流水线标签标识：“type=MASTER,PRE_RELEASE” “category=INTERVAL”  。

• 多人共享分支预发布环境部署类流水线标签标识：“type=SHARE,PRE_RELEASE” “category=INTERVAL”  。

• 主干自动化测试稳定性流水线标签标识：“type=MASTER” “category=RELIABILITY”  。

• 多人共享分支自动化测试稳定性流水线标签标识：“type=SHARE” “category=RELIABILITY”。

4.2 关于提交构建和次级构建流水线规范：

1）针对被标记为MASTER和SHARE的日常部署流水线

应包含提交构建，在持续集成平台上定义Label 为“category = MAIN”。

触发条件：相应的代码变更后自动触发。

必须包含单元测试自动化任务。所有单元测试任务的命名均以“UT-”开头。关于“单元测试”的定义参见0B.自动化测试相关规范说明。

• UT-自动化测试任务结束后应将测试结果报告打包上传到持续集成平台保存。

• UT-自动化测试任务结束后应将下列信息保存到本次构建的属性列表中。

• 执行总时间：UT-totalTime

• 总用例数：UT-TotalCaseNumber：

• 失败用例数：UT-FailedCaseNumber

• 成功用例数：UT-PassedCaseNumber

• 未执行或跳过用例数：UT-SkipCaseNumber

• 单测增量测试行覆盖率(如有)：UT-PART-Coverage

• 单测全量测试行覆盖率（如有）：UT-FULL-Coverage

• 如果为了提升速度，有多个UT-任务并行，上述属性应是汇总后的数据。

• 不可移到次级构建或定时构建中。

• 必须配置单元测试执行通过率的质量红线，且配置通过条件为单元测试执行通过率不低于100%。

必须包含代码规范扫描类任务。若有多个代码规范扫描任务，任务命名均以“CCK-”开头。若由于全量扫描时间过长，且该任务失败率低，可以将其放入定时构建流水线执行检查。

• CCK-类的扫描任务应该将会结果报告打包上传到持续集成平台保存。

• CCK-类的扫描任务结束后应将下列信息保存到本次构建的属性列表中。

• CCK-类的扫描任务可以有多个，如CCK-LINT或CCK-SONAR等等。

• 必须配置代码扫描的质量红线。

建议包含“BVT-”开头的build verification test。

• BVT是一套自动化BVT验证集。包括最基本的软件验证（相当于硬件开发流程中的冒烟测试）。

• BVT测试任务结束后应将下列信息保存到本次构建的属性列表中。

• 执行总时间：BVT-totalTime

• 总用例数：BVT-TotalCaseNumber：

• 失败用例数：BVT-FailedCaseNumber

• 成功用例数：BVT-PassedCaseNumber

• 未执行或跳过用例数：BVT-SkipCaseNumber

备注：若单元测试用例和BVT用例合并在一个用例集中：

• 可将两个任务合并为一个测试任务，任务命名均以“UBVT-”开头。

常见的优化提交构建耗时方法：

• 增加流水线并发布执行stage，减少执行耗时关键路径长度。

• 分析流水线执行耗时分布，优化各个环节耗时。

• 拉代码环节，避免使用 fresh-checkout 模式。

• 编译环节，使用模拟器编译或分布式编译、组件化增量编译、增加编译任务执行并发数。

• 耗时较长的工具比如coverity扫描放在定时触发类流水线中。

• 精准测试、增量测试方法引入，提升该流水线自动化测试耗时。

• 优化执行测试用例内容，可以将部分测试用例转至次级构建。

2）如果提交构建中执行的内容过多，运行时间过长，且无法继续优化提交构建执行耗时，可以建立一个后续构建，即“次级构建”。

• 该构建在持续集成平台上定义Label 为“category = SECONDARY”。

• 触发条件：提交构建成功完成后自动触发。

• 该构建中的任务包含但不限于“BVT-”开头的build verification test。BVT测试集可以包含：

• 逻辑层自动化测试用例

• UI/Interface自动化功能测试用例

• mini性能测试(根据时间约束)

• 安全测试(根据时间约束)

4.3 针对被标记为RELEASE的验证流水线

RELEASE流水线应该进行发布前的自动化校验。

自动化检验结束后，应有一个对接自动化发布系统的Stage，该Stage名称为“DELIVERY”或者以“DELIVERY”开头。

对接的自动化发布系统应该向CI系统回写数据，标记本次操作的结果（成功 or 失败）。

若该RELEASE分支的代码全部来自于主干集成分支。

• 该流水线就运行重要的自动化检查，并向移动端预发布环境/后台金丝雀环境部署。

• 自动化检查可包括：

• 部署检查

• 主要功能检查

• 该版本主要内容检查

• 预发布环境的自动化验证

若在该Release分支上直接修改代码或直接修复bug。

该流水线的设计方式应该尽可能与主干生产流水线一致。

4.4 个人分支的部署流水线

个人分支对应的流水线至少应该执行其父分支对应的常规流水线中提交构建的相同内容。

参见《持续交付 2.0》第7章“部署流水线原则与工具设计”中，第 7.2.1节 “流水线的设计原则”。

参见《持续交付 2.0》第9章“持续集成”中，第9.3节“速度与质量的平衡”。

优化产品软件的构建脚本。

优化软件代码架构，进行组件化构建。

参见《持续交付 2.0》第9章“持续集成”中，第9.2.3节 “自查表”。

质量红线是指通过设置质量标准，控制流水线的行为，使得其产出物必须符合质量标准的一种服务。它能够支持Git Merge Request、日常构建、版本转测、版本发布等场景下对软件产品质量的保证。

质量红线支持设置CodeCC代码检查的指标，包括代码缺陷、代码安全、代码规范、重复代码、复杂度等五大维度、十余款工具的产出物。对于一些个性化的的指标，例如单元测试、自动化用例测试等，可以通过创建一个自定义指标，然后通过脚本任务原子上报数值，来使用质量红线的功能控制流水线。

应包含规则名称、规则ID、指标、控制点、生效范围、操作的设置。

• 必须包含规则名称，且名称清晰表明规则的用途。所有单元测试的质量红线的命名均以“单元测试”开头，所有非单元测试的自动化测试质量红线的命名均以“自动化测试”开头。

• 要求包含规则ID，仅支持英文和数字。质量红线只对名称以规则ID加下划线开头的控制点生效。

• 必须设置指标（支持自定义指标）。

• 必须设置控制点，包含控制点名称和红线位置。

• 必须设置生效范围，关联到具体的部署流水线。

• 必须设置操作，可选择“终止后通知”或“人工审核”。

乔梁老师开课啦~视频课程《持续部署训练营（Python版）》， 限时特价！

你的软件开发效率够高吗？质量够好吗？你的团队多长时间才能向用户实时推送一个生产变更？你的软件在发布时，你是否因担心软件交付质量而感到压力倍增？你是否遇到过部署失败，甚至导致停机的情况？持续部署可以帮助你消除软件交付的痛苦，让你能专注于为客户高价值的需求，而不会因为这些交付执行类问题而花太多精力。本课程通过学练结合，理论结合实战，让你体验如何使用构建-测试-部署管道，进行持续部署。并练习如何在有效监控部署的同时，逐步发布功能特性，并作数据库结构变化。

（扫码订阅）