提交代码「前置处理」,向前一小步,效率提升「亿点点」


在开发过程中,开发人员提交代码后,需要继续做很多工作,因此我们不由萌生一个问题:是否可以把一些工作前置处理,减少等待时间?
 
首先,我们先回顾一下常见的代码流程:
 
 
  1. 1. 开发人员在本地编写代码之后,执行 Git Commit 操作 ,保存本地仓库;
  2. 2. 将代码推送到远端服务器,触发 CI Pipeline,执行 Pipeline 中各阶段任务:Build、Unit test、Integration test;
  3. 3. 执行 CD Pipeline 阶段任务:Review、Staging、Production。
 
在该流程中,若在本地发现问题,修复起来时间相对较短;若在远程执行 Pipeline 后才发现问题,则修复时间较长,并且增加了服务器的压力。
 
 
那么是否可以将一些工作提前,如在中间部分(如上图)完成来提高本地效率,缩短开发流程呢?如题所言“向前一步”,即把原本在 CI 中执行的
部分工作,放在本地执行。
 
代码流程中的后置处理之痛
 
常见代码开发过程中,通常依赖于后置处理,即开发人员的代码提交到 Git 上以后,运行 CI/CD 或者 Code Review 过程中才发现常见问题,包括:
 
  • 代码规范 → 花大量时间沟通达成一致;
  • 冲突与错误 → 提交后发现与主分支冲突,需要重复修改代码和提交;
  • 敏感误提交 → 可能造成安全事故;
  • 缺少自动化任务 → 手动执行,容易遗忘。
 
这样既浪费了 CI/CD 资源,也花费了不必要的时间,导致开发效率低。
 
举个🌰,如下图极狐GitLab 中的 Pipelines,在构建作业 → 测试 → 发布的环节中,我们需要等上传测试后才能发现错误,接着在本地修改,再把 Pipeline 推送上来,才能确认这个错误是否被修复;若没有修复,则需要重复修改,直至修复完成,这个过程耗费很多时间。
极狐GitLab

 

 
可能大家会想到,对团队成员进行口头约束,或从制度上要求开发人员必须自己做检测,但这些几乎是流于形式。
 
那么,极狐GitLab 如何处理解决这些问题的?
 
极狐GitLab 自动化流程落实前置处理
 
极狐GitLab 通过自动化流程,高效落实开发工作,让团队协作更流畅。
 
  • 代码规范性问题
  • 在提交代码前,运行代码风格检查和自动化测试等脚本,帮助开发人员发现并修复代码中的规范性问题,从而保证代码的质量和可维护性。
 
  • 冲突和错误问题
  • 在提交代码前运行 Git Hook,帮助开发人员避免将错误或不规范的代码推送到代码仓库中,从而减少代码冲突和错误。
 
  • 工作流程问题
  • 开发人员规范化 Git 工作流程,提高工作效率和协作效果。通过配置 Git Hook,可以自动化执行代码检查、测试、构建和部署等任务,避
  • 免手动操作繁琐和出错。
 
极狐GitLab 在具体实践中逐步完善了该自动化流程,从而确保研发任务能更有效执行。这部分在极狐GitLab 的文档里也有更具体说明,感兴趣的
小伙伴可以查阅我们的资源与文档(https://docs.gitlab.cn/jh/)
 
前置处理的关键方法:Git Hook
 
与许多其他版本控制系统一样,Git 有一种方法可以在发生某些重要操作时,触发自定义脚本,即 Git Hook(Git 钩子)。
 
 
当我们初始化一个项目之后,.git 目录下有一个 hooks 目录,可以看到上图左侧有很多执行任务,比如 pre-commit,代表在运行这些命令之后或
之前,会进行一些校验和检测来执行相应任务。
 
Git Hook 分为两部分:本地和远程,如下图所示:
 
 
本地 Git Hook,由提交和合并等操作触发:
 
  • 比如代码发生变更,进行 git add,把 message 进行 commit changes;
  • 当 git commit 时,就会执行一个钩子叫 pre-commit(准备提交钩子)。
 
远程 Git Hook,运行在网络操作上,例如接收推送的提交:
 
  • 在 commit 之后,要推送到远端,此时有一个叫 pre-push 钩子,把信息推送 git 仓库;
  • 在远程阶段,极狐GitLab 相当于一个远程仓库。如图有很多仓库,分别承担不同功能,比如 pre-receive ,主要在服务器端接收通过本地
  • 推上来代码,然后 update 相关代码,post-receive 说明代码接受成功,同时有一个服务器钩子执行。
 
在这里,我们主要关注本地 hook,比如说 pre-message 和 pre-push,因此我们会借助这些工具来实现规范化代码内容。
 
提前进行代码规范检测
 
极狐GitLab 是一个非常大的代码仓库,包含前端代码、后端代码,还有运维相关代码:
 
  • 前端代码如 ESlint、Jsonlint、HAML-lint、Markdown-lint;
  • Ruby 相关的如 RuboCop、Stylelint;
  • Yaml 相关的如 Yaml-lint。
 
当然也支持不同语言项目,像 Python、Java 或者其它编程语言,也会有相应代码规范要求,可以自己添加。
 
每个 Lint 都会去检测代码中的变动,从而检测代码是否符合预期。只有符合预期的代码,才能够推送进来,避免代码提交之后,再发现代码规范
问题,在反复修改上浪费时间。
 
这就好比整个代码仓库是房子,代码是水,Lint 相当于过滤器,必须让这些代码经过过滤后,才能从水龙头流出,成为生活用水。
 
提前进行代码安全检测
 
下图展示的是 GitHub 安全事故:很多人在测试或调试代码过程中,把一些 Token 放在里面,无意识地推送到仓库中,导致 API 和加密密钥泄露,这很容易被人发现和利用,进而造成巨大损失。
 
 
极狐GitLab 十分注重代码安全,我们必须想办法阻止开发人员将密钥提交到仓库,也就是必须在 Commit 之前,阻止开发人员把密钥信息给放到
Git 历史记录中。
 
那么,常见的安全代码检测工具有哪些?这里给大家提供一个参考,就是 Gitleaks。
 
Gitleaks 是一个 SAST 静态代码检测工具,检测代码中常见的 Secret、Token、Password 等内容,生成 Secret 检测报告产物,避免误提交,提高
研发安全性。
 
 
提前进行自动化内容检测
 
上述代码规范检测、代码安全检测,都是在代码提交前,及时发现问题和解决问题,提升代码质量和安全性。自动化内容检测偏向于常规性内容
检测,例如:
 
  • gettext:查找未翻译的内容,提示开发人员及时翻译;
  • docs-metadata:提醒开发人员为文本添加描述等;
  • graphql-doc:检测 graphql 的 doc 是否完整;
 
自动化内容检测避免代码提交到在服务器后再去修改内容,也是提高开发效率的手段之一。
 
上述 3 个步骤放在本地开发阶段执行,基于以下原因,开发效率就会有很大提升,甚至整个运行时间降低 50%,同时更高效地提升了代码质量:
 
  • 本地运行速度快;
  • 及时发现问题,减少沟通协作成本;
  • 节省 Code Review 时间;
  • 节省 CI/CD 运行资源。
 
友好的 Git Hook 管理工具:Lefthook
 
我们可以使用 Git Hook 里的 bash 脚本来编写,比如前面提到的 Eslint、Stylelint 等,但是这种方式有个比较大的缺点:无法放在仓库中,则无法
看到变更历史,也不方便分发,而且可能不是每个开发人员都熟悉脚本的开发。
 
因此,我们可能需要更友好的 Git Hook 管理工具,这里推荐工具:Lefthook。
 
什么是 Lefthook?
 
Lefthook 是一个开源的 Git Hook 管理工具,帮助开发人员自动化和规范化 Git 工作流程。
 
Lefthook 具备以下特点:
 
  1. 1. 支持多种编程语言:包括 Python、JavaScript、Ruby、Go、Java 等;
  2. 2. 简单易用:轻松安装和配置,使用过程也非常简单;
  3. 3. 高灵活性:允许用户在 Git Hook 中使用任何语言和工具,而不仅仅是 shell 脚本;
  4. 4. 高可扩展性:可与其他工具和系统集成,比如 CI/CD 工具、代码检查工具、自动化测试工具等;
  5. 5. 支持跨平台:支持 macOS、Linux 和 Windows 等多个平台。
 
如何使用 Lefthook?
 
前文介绍了本地开发的前置一步,接下来通过实例让大家体会一下在前置处理中,如何使用 left hook 处理代码的风格安全问题。
 
 
上图是我第一次编辑的一段 Ruby 代码:通过 ChatGPT 抓取 GitHub issue 的一个内容。可以看到,acces-token 是一个环境变量,生成一个client
接口,接着我们去抓取相关 issue 信息,最后把它们打印出来。
 
这段代码无论从风格上还是从安全性上来说,都是一个很简单的内容。
 
 
假设本地开发人员对这段代码进行了二次编辑,他发现设置本地变量比较麻烦,直接把密钥写在代码中(如上图。密钥为随机值),同时还把代
码风格打乱了,空了很多多余行,换行也是往后对齐,导致整个代码乱糟糟,不符合规范。
 
把这段代码推送到 CI 上,就会被检测出问题,或者 Code Review 发现这些Token 不应该上传,但这样属于事后处理,实际上,我们应该在提交之
前处理掉这些问题。
 
那么我们看下 Lefthook 的配置, Lefthook 是类似一个 yml 的文件的配置。如下图,这里有一个 pre-push 的 hook,还有推送前的一个命令叫
pre commit。这里我们着重讲讲 pre-commit。
 
pre-commit 它运行两个方面:
 
  1. 1. Rubocop 风格检测:对 .rb 后缀的文件进行入库,检测是否符合规范
  2. 2. 密钥检测:检测文件中是否发生了密码的泄露
 
 
当我们在 commit 时,就会运行这两个命令,检测提交的代码内容。
 
 
检测上图这段糟糕的的代码时,看到执行钩子 pre-commit 后的效果:
 
  • 密钥检测提醒第七行有一个 api key 泄露,确实左边第七行用了一个明文密钥;
  • 风格检测提醒 15-17 行是多余空行,第 25 行写法不符合规范。
 
从而这段代码报错了,阻止 commit 的提交。
 
发现这些问题之后,就可以直接在本地去修复了,不用等待 CI/CD 时间;修复完再次提交,就成功了,可以看到 CI/CD 正常运行,让 CI/CD 在
测试期间也能正常通过,效率就大大提高了。
 
 
除了这些内容,我们还会进行一些常规检测,比如在 Lefthook 配置里,有一个叫 Ruby 代码风格检测工具 Rubocop,有一些命令可以修复大部分
错误内容,我们也可以加入一些自定义命令,如出现问题,自动修复并推送到服务后,给钉钉发送信息等。
 
极狐GitLab 中,大概有十几个 Lefthook 命令,在开发过程中自动发现常见问题并解决。
 
总结
 
很多时候,造成效率低下的原因,是发现问题的时机太晚,Git Hook 在本地就能帮助我们解决代码规范问题、代码安全问题,并通过自定义脚本
内容来自动执行,减少CI/CD、Code Review 时间,整体提升开发效率。