无序和混乱终结者，极狐 GitLab Workflow 到底有什么魔力？

效率和质量是软件产品追求的两个核心关键点，软件产品研发是一个覆盖多阶段、涉及多团队的过程，业界也已经总结出了一些很好的实践，在保证研发效率的同时还能保证代码质量。比如代码提交规范、Code Review、代码准入、CI/CD。

但是由于缺乏行之有效的研发流程规范，让上述实践在落地的时候往往流于形式、可有可无，让保证质量、提升效率成为悬而难落的话题。而代码提交不规范、不同开发模式下代码审核与准入环节的缺失是导致质量与效率双双下降的重要原因。

所见非所得的代码提交

代码变更提交信息能够让外界对所变更的代码有一个快速、清晰的认知，可以初步判断出变更代码的类型（新 feature 上线、bug fix、文档修复等），变更代码的范围（某个接口的增删改、某个功能的增删改等），不仅利于代码审核人员对于审核代码有一个初步认知，也有利于出现问题之后的问题回溯，更重要的是有助于提高代码的可维护性。

代码提交规范是每个企业都在追求实践的，但并非所有的企业都能够通过流程 + 工具将规范进行到底，尤其在项目需要紧急上线，bug 需要紧急修复时，下面的这种代码提价信息也就变得比较常见了：

4deaaed (HEAD -> main) add new feature
5224286 fix api bug
2506aa2 fix typo
70819a2 delete useless code

看似懂了又似乎没懂的代码提交信息折射出了不规范的代码提交带来的后果：所见非所得。

简单但是熵增的开发模式

基于 “主” 分支的开发

由于 git 使用的复杂性，当团队的 git 使用技巧（分支的管理、代码的回退等）达不到一定程度时，在业务提交紧急时，git add && git commit && git push 就成了代码提交三步曲，变更代码被直接推送到主分支，走先提交再验证的流程。

这是看似快捷方便的代码提交会带来以下问题：

逐渐失控的代码仓库

代码都是直接推送到 “主” 分支，代码没有先经过验证就提交，容易导致有问题的代码被合并到主分支，主分支可能会随时被阻塞，难以保证主分支实时可用、可交付的状态。另外，在不做提交文件限制（比如 pem、jar、war 等）的情况下，随着功能的迭代，代码仓库就会 “爆仓”逐渐失控。

无法保证质量的代码

代码变更都是先提交再去验证（提交之后，在主线验证），在提交前或提交后都不做 Code Review，代码的质量是难以保证的，最终导致产品的整体质量下降。

返工严重，耗时耗力

代码提交到主分支上，验证不通过就需要返工进行故障查找和修复。由于缺乏提交前的充分验证和审核，就会导致这种返工是频繁的、耗时耗力的。

基于 “多” 分支的开发

当然，随着团队对于 git branch 的熟悉，基于 branch 的业务开发也成为被很多团队所采用的开发模式。开发人员不管是上线新功能还是修复缺陷，都是先创建一个新的分支，基于这个新分支完成代码变更，经过验证之后再合入主分支。

这种模式虽然能够让开发者之间 “互不干扰” 的进行开发，也能够比上述基于 “主干” 分支的开发，让 “主干” 分支被阻塞的时间大大缩短，但是依旧存在代码质量无法保证的问题，因为缺失了两个关键环节：

1. Code Review

Code Review 是保证代码质量的有效一环。“只要眼睛多，bug 容易捉”，如果让其他同行人员对于代码变更进行 Review，不仅能够对于变更代码是否符合业务逻辑做一些检查，还有可能发现一些潜在的缺陷，并且将反馈直接反馈给代码提交者，在修复之后再进行代码提交。很多时候，这种 Review 可能是多个回合，对于代码质量的提高是非常重要的。

2. Approve Rules

代码的合并需要有一定的准入规则，一来可以防止代码提交者自己直接进行代码合并，二来需要确保变更的代码是经过了充分验证的，诸如需要经过 QA 的验证确认、需要安全团队的安全扫描确认等，才能够有特定的人员批准代码的合入，变更代码才会最终进入到主分支。

不管是上述的哪种开发模式，都没有将项目管理、代码变更、代码审核、代码准入完整的串起来，形成真正的规范化的研发流程来在保证效率的同时，保证代码质量。

因此，寻求一个可以落地、可以推广的规范化研发流程，是可以帮助研发团队将一些想实施但是容易流于形式的做法真正实践起来，真正的帮助团队提高研发效率、保证代码质量。而这一规范化的研发流程有几个要素是不可或缺的：

所有变更的发起都要有迹可查，有地方记录变更发起的原因，范围等；

所有变更代码都要强制执行 Code Review，避免流于形式；

所有变更代码的准入要有一定的规则，只有被特定人员批准的代码才可合入主分支；

所有变更代码从构建到部署尽量自动化，避免过多手动步骤。

极狐 GitLab Workflow

极狐 GitLab Workflow 通过将需求管理、代码审核、CI/CD、代码准入、安全扫描等流程融合在一起形成规范的标准化研发流程，能够提高不同团队、不同人员之间的协作效率，加速软件产品从想法到生产上线的速度，而且整个过程能够保证代码的质量和安全。

一切变更从 issue 开始

对于软件产品的任何变更，诸如新功能添加、缺陷修复、安全补丁升级等，都应该有所记录，这会让故障回溯、安全审计变得更容易。

极狐 GitLab Workflow 的起始就是利用 issue 来完成对于所需变更的详情描述与记录，而且可以通过 issue assign 来指定具体的负责人对 issue 进行处理与跟踪。

比如针对一个需要修复的缺陷，可以通过下面的方式来完成缺陷的记录：

在 issue 描述中可以详细描述缺陷的特征、发现的版本、如何复现、期望修复时间等信息方便修复人员对于缺陷有更清晰的认识，再通过 assignees 来指定 issue 的具体负责人，将修复责任落到实处。

此外，Epic、Milestone 等极狐 GitLab 项目管理功能有助于项目管理人员对缺陷的修复进度进行查看与把控。

基于分支的开发

创建完 issue 之后，可以创建一个 MR（Merge Request）来实现基于分支的开发，后续的所有操作（代码变更、CI/CD、代码审核等）都与此 MR 相关联，这也完成了 issue 与 MR 的关联。

极狐 GitLab Workflow 支持在 issue 创建的同时创建 MR，而且可以指定要创建的分支：

Code Review + Approve Rule，严格把控代码质量

可以在 MR 中直接指定 Reviewer 对于 Code 进行 Review，而且可以指定多个 Reviewer。Reviewer 可以在提交的变更文件中进行代码 Review，如果需要添加 Review 意见，直接在对应的代码行数前点击 comment 图标，即可出现添加 Review comment 的方框，输入 Review comment，点击 Start a review 即可。

代码提交者可以根据 Review comment 进行相应的修改，在确定可以合并后，即可和 Approver 进行沟通，进行代码合并。

可以通过添加 Approve Rules 来对代码的准入规则做限定：

比如可以指定对应的 Approver 以及最少 Approve 人数以及 Rules 生效的分支：

而且可以通过额外的设置还组织代码提交者自己进行 Code Approval、组织随意修改 Approval Rule 等，来进一步规范 Code Approval 流程：

这种多人进行 Code Review，多级进行 Code Approve 的机制，形成了把关代码质量的双保险。

CI/CD 实现变更的自动化构建

CI/CD 能够完成变更代码的自动化构建、测试、安全扫描等，不仅能够加速代码从变更到部署的速度，也保证了每次代码变更都会经过同样的构建、验证流程。而且最重要的是 CI/CD Pipeline 的构建结果、测试结果、安全扫描等结果都可以直接反馈到 MR 中，为 Code Approver 提供数据决策：

没有规范可落地的研发流程就无法在团队、组织内推广提高代码质量与提升研发效率的一些最佳实践。

极狐 GitLab Workflow 通过将需求管理、代码质量保证、CI/CD、安全防护等手段融合在一起，用流程 + 配置的方法让流于形式、难以落地的实践都发挥真正的作用，实现用标准化研发流程来实现效率与质量的双提升。