共计 3290 个字符，预计需要花费 9 分钟才能阅读完成。
效率 和品质 是软件产品谋求的两个外围关键点，软件产品研发是一个笼罩多阶段、波及多团队的过程，业界也曾经总结出了一些很好的实际，在保障研发效率的同时还能保障代码品质。比方代码提交标准、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、平安防护等伎俩交融在一起 ，用 流程 + 配置 的办法让流于形式、难以落地的实际都施展真正的作用，实现用标准化研发流程来 实现 效率与品质的双晋升。
