本文我将从为啥我们要做质量流水线？在流水线上我们做了哪些？我们如何落地？等方面去介绍质量流水线。

什么是质量流水线

质量流水线（Quality Pipeline）我个人的理解是指在软件研发过程中，确保高质量的软件的一套方法。它是一种结合 DevOps 流水线，在研发测试流程中尽可能自动化、标准化、规范化等提高软件质量和稳定性，减少软件开发的风险和成本。

为啥要做质量流水线

为啥要做，其实也是我们这个质量流水线的背景，我们看到了目前研发流程上的问题，并把问题归类成以下三大类：

测试过程记录欠缺

我们公司自研了研发效能平台，通过 Flow、Story、上线工单等去承接了需求、研发和上线过程，但对测试过程的记录欠缺，需要对其进行补充完善。

人为操作频繁且易出错

我们公司已经有一套相对完善的研发流程，但从研发创建代码功能分支开始，到代码上线结束，这个漫长的过程中，非常多的环节都是靠人为去操作，人为去检查、把关。人为操作就容易出现疏忽，遗漏。例如在做这个项目之前，我们公司几乎每个月都会出现因为代码漏合并，漏拉取最新代码，测试封板后研发又动代码，测试未能及时感知，造成把未经过测试的点上线等原因，造成线上 Bug。

平台互相割裂

我们公司已有研发效能平台，测试管理平台、运维、DBA 等等平台，每个平台都提供了自己领域的专项功能，但是平台间交互较少，在真实用户使用过程中需要在多个平台切换，从而也增加了使用和学习成本。

制定目标

那么我们发现了问题，也对问题做了归类，那自然就想办法去解决这个问题，所以就有了我们这个质量流水线项目。我们对这个项目提出需要打成的目标和大概方案：

闭环测试过程

通过测试单和上线单的承载，完整闭环提测到上线整个过程。

提供上线标准

需要制定质量门禁，为提测和上线提供质量结果指标。

提高测试质量

封闭提测版本后代码有变动，及时通过流程阻断或者通知等方式避免代码未经过测试就上线。

提高研发效率

我们让研发专注于业务开发，把代码合并，分支管理等全流程自动化，简化研发和测试的工作内容，降低操作不规范引起的问题，减少人工污染。

一键打包部署

在原有的意见打包基础上，重新设计，提供一站式的 DevOps 流水线，不仅仅做到一键打包，结合分支管理和测试工单我们希望能做到持续集成，持续部署，再结合自动化平台和静态代码分析平台做到持续测试。

目标落地

制定目标后我们需要细化每个目标需要做的需求点，并召集多方平台人员进行需求分析，明确各方职责，简单形成一个大体的交互流程图，如下
流程图
流程图看起来很长，其实上面橙色部分是全部自动化，蓝色和绿色分别是研发和 QA 需要操作的。
然后里面因为涉及很多东西，我这边拿几个比较有代表性的目标落地做介绍。

测试工单，提供质量门禁

我们在研发效能平台的研发流程中加入测试工单，通过测试工单记录提测的内容，同时在测试工单上聚合测试的结果，并为研发提测和上线提供质量门禁。
如下图是一个真实测试工单的测试结果相关信息展示，我们在工单上聚合了测试平台的测试计划结果，功能覆盖率，代码覆盖率，用例执行情况，Bug 关闭情况，还跟 DBA 相关平台打通，确认是否存在慢查询等问题。同时每个指标，支持全局或者自定义的质量门禁，如果未达到质量门禁，那么在工单进行提测、审批或者转成上线工单等均会给明确的警告，并做相关数据埋点。那测试工单记录相关提测信息和测试过程结果信息，也为后续追溯问题做好留底。

闭环代码分支管理

在讲这个之前，我先简单介绍下原本我们公司 Git Flow 的分支管理流程。如下图。 相信这个是绝大多数公司的 Git Flow，他基本是参考了 GitHub Flow 的一个分支管理策略，这种策略最大好处就是在测试环境少的情况下，非常适合多版本并行，但他同样有非常多的槽点。

1. 流程繁琐：新建 Feature 分支，合并到 Dev 分支测试，测试完成拉取 release 分支打 tag 上线，如果开发环境和测试环境各一套，可能还会存在多个的 Dev 分支。
2. 纯手工：创建分支，合并分支，打 tag 等等均需要人为操作，而这些操作如果不按规范来或者检查不到位，就容易出现遗漏，也就是我上面提到我们几乎每个月都有一些线上问题，归因后均是因为代码漏合并合并错误，忘了更新等引起的线上 Bug。
3. 无法代码封闭：哪怕 QA 在 relase 分支测试完成，达到上线标准，研发均可能继续手动往 relase 分支上做合并代码，或者重新生成 relase 分支代码，这些均需要 QA 自行做 Code Diff 检查感知。

所以基于以上那么多的槽点，我们参考业界很多方案，最后参考阿里的 OneFlow，再结合我们的测试单和实际情况制定了我们自己的 Git Flow 2.0 。
Git Flow 2.0 结合测试工单和后面要讲的 DevOps 流水线一起使用，我们可以做到简化分支，我们只保留了 Master，Feature 和 Release 分支，而且 release 分支是由多个 feature 分支自动合并生成的分支，这里我们就做到了代码持续集成，免去研发合并代码的动作。同时我们为了保证测试的代码一定是包含线上最新的代码，或者说自己功能上线把别人的已上线功能干掉，我们还做了自动从 master 去创建出 relase 分支。
QA 同学直接使用自动生成的 release 分支做测试。为了达到测试完成后封闭代码，我们做了一系列的自动检查。 封闭代码后，一旦代码有变更，如果测试不重新打包测试，我们做到流程阻断，例如 tag 不让生成，tag 生成后继续改代码，那就打包不让通过等等自动化检查。那这样有啥好处？
我们可以保证上线代码就是测试代码，所有上线代码都是经过测试才上线，避免避免测试完成后研发又改了代码等带来的风险。
最后代码上线后，我们还做了自动把代码合并到 master 分支，避免以前研发需要手动合且经常遗忘合并的问题。
当然我们也逐步回收一些权限，例如 Release 分支绝不允许研发做合并，tag 只能通过平台生成，不允许研发自己删、打。
那这个 git flow 同样也有缺点，就是分支都自动生成，容易生成较多无效的分支，但是这个问题我们已经解决， 我们通过规则，自动回收产生的 feature 和 release 分支，这个上线 1 个多月了，目前也是很稳定。

这个 Git Flow2.0 结合我们工单和 DevOps 流水线的一个具体案例，我们让研发 Story 下新建或者关联 feature 分支，在提测 Story 时一键把分支导入到测试工单，通过测试工单上的触发流水线按钮，触发 DevOps 流水线，从而做各种自动检查等。
这个 Story 关联或者创建 Feature 代码分支，看似一个很小的动作，但这个动作也为我们后续研发效能中很多指标提供了基础数据，例如后续如果想知道这个功能模块或者对应 Flow 需求的研发质量怎么样，我们可以通过分支代码量和 Story 的缺陷数去计算出千行 Bug 率等指标。
Story:

测试工单：

DevOps 流水线

上面工单中提到的，触发流水线就是我们落地的 DevOps 流水线。我们先一张图看懂我们 DevOps 做了啥？

上图就是一个完整的 DevOps 流水线执行结果，这个流水线实现了从代码检出（release 生成，feature 合并等），编译测试（单元测试，sonart 扫描，安全扫描等），制品生成，制品发布到最后的对接自动化平台执行自动化测试。
一目了然我们就是实现了持续集成，持续部署，持续测试。
同时跟测试、上线工单结合，把原本割裂的多个平台如 Sonar、Jenkins、研发效能、自动化平台等通过流水线做了入口聚合，同时对用户使用，只再研发效能平台上提供了一个触发流水线按钮，极大简化了操作。

总结

以上就是我们做的几个重要内容，基本是能完成一开始设定的目标，这里简单做最后的一个总结：

规范化

我们在原有的研发流程规范中，加入测试工单，重新制定了 GitFlow，也标准化了流水线作业。

线上化

通过质量流水线和 DevOps 流水线，承接整个研发流程规范。

数字化

提供质量门禁卡点，关键指标埋点，统计为后续能效提供基础数据。

自动化

自动化的持续集成和持续交付工具，通过构建自动化、集成自动化、验证自动化、部署自动化。

一体化

把割裂的软件交付流程收敛到统一的入口，统一的流水线平台。

后续思考

我们 Git Flow 2.0 抛弃了原来的 Dev 分支，做了自动代码合并，但用户真实使用场景里面还是存在不少的多版本并行情况，主要是在一个版本已经提测了，下个版本也需要提测且和上个版本存在相同的服务，但我们测试环境就 1 套的情况下，就必须合并 2 个版本代码一起测试，那就不得不把两个版本的代码分支放到一个测试工单上去自动合并分支。尽管我们是可以通过测试工单自由去组织要提测的 Feature 分支，可以自由的增减，自由的组合，但是这样就增加了工单编辑和状态回退的次数。
那这个问题也不是无解，理想状态就是每个版本有自己的一个独立测试工单，独享一个测试环境，但是这样并行多个版本就需要多个测试环境，如果按传统的多环境方案搭建，不管从人力成本和资源成本以及后续的维护成本都是巨大的消耗，以此我们这个 Q 也开始搭建我们自己的泳道环境。
那关于泳道环境的搭建过程和思考以及落地，那就等下次再来细讲吧。
关于上面提到的测试平台，其中用例管理和代码覆盖率可以查看对应文章。
破（bei）卷之路 - 代码覆盖率统计
聊聊用例管理平台

原文：https://www.yuque.com/testdevops/devops/ogf3bm6xv2ivbcr9