在开发过程中,开发人员提交代码后,需要继续做很多工作,因此我们不由萌生一个问题:是否可以把一些工作前置处理,减少等待时间?
首先,我们先回顾一下常见的代码流程:
-
1. 开发人员在本地编写代码之后,执行 Git Commit 操作 ,保存本地仓库;
-
2. 将代码推送到远端服务器,触发 CI Pipeline,执行 Pipeline 中各阶段任务:Build、Unit test、Integration test;
-
3. 执行 CD Pipeline 阶段任务:Review、Staging、Production。
在该流程中,若在本地发现问题,修复起来时间相对较短;若在远程执行 Pipeline 后才发现问题,则修复时间较长,并且增加了服务器的压力。
那么是否可以将一些工作提前,如在中间部分(如上图)完成来提高本地效率,缩短开发流程呢?如题所言“向前一步”,即把原本在 CI 中执行的
部分工作,放在本地执行。
代码流程中的后置处理之痛
常见代码开发过程中,通常依赖于后置处理,即开发人员的代码提交到 Git 上以后,运行 CI/CD 或者 Code Review 过程中才发现常见问题,包括:
这样既浪费了 CI/CD 资源,也花费了不必要的时间,导致开发效率低。
举个🌰,如下图极狐GitLab 中的 Pipelines,在构建作业 → 测试 → 发布的环节中,我们需要等上传测试后才能发现错误,接着在本地修改,再把 Pipeline 推送上来,才能确认这个错误是否被修复;若没有修复,则需要重复修改,直至修复完成,这个过程耗费很多时间。
可能大家会想到,对团队成员进行口头约束,或从制度上要求开发人员必须自己做检测,但这些几乎是流于形式。
那么,极狐GitLab 如何处理解决这些问题的?
极狐GitLab 自动化流程落实前置处理
极狐GitLab 通过自动化流程,高效落实开发工作,让团队协作更流畅。
极狐GitLab 在具体实践中逐步完善了该自动化流程,从而确保研发任务能更有效执行。这部分在极狐GitLab 的文档里也有更具体说明,感兴趣的
小伙伴可以查阅我们的资源与文档(https://docs.gitlab.cn/jh/)。
前置处理的关键方法:Git Hook
与许多其他版本控制系统一样,Git 有一种方法可以在发生某些重要操作时,触发自定义脚本,即 Git Hook(Git 钩子)。
当我们初始化一个项目之后,.git 目录下有一个 hooks 目录,可以看到上图左侧有很多执行任务,比如 pre-commit,代表在运行这些命令之后或
之前,会进行一些校验和检测来执行相应任务。
Git Hook 分为两部分:本地和远程,如下图所示:
本地 Git Hook,由提交和合并等操作触发:
远程 Git Hook,运行在网络操作上,例如接收推送的提交:
-
在 commit 之后,要推送到远端,此时有一个叫 pre-push 钩子,把信息推送 git 仓库;
-
在远程阶段,极狐GitLab 相当于一个远程仓库。如图有很多仓库,分别承担不同功能,比如 pre-receive ,主要在服务器端接收通过本地
-
推上来代码,然后 update 相关代码,post-receive 说明代码接受成功,同时有一个服务器钩子执行。
在这里,我们主要关注本地 hook,比如说 pre-message 和 pre-push,因此我们会借助这些工具来实现规范化代码内容。
提前进行代码规范检测
极狐GitLab 是一个非常大的代码仓库,包含前端代码、后端代码,还有运维相关代码:
当然也支持不同语言项目,像 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. 支持多种编程语言:包括 Python、JavaScript、Ruby、Go、Java 等;
-
2. 简单易用:轻松安装和配置,使用过程也非常简单;
-
3. 高灵活性:允许用户在 Git Hook 中使用任何语言和工具,而不仅仅是 shell 脚本;
-
4. 高可扩展性:可与其他工具和系统集成,比如 CI/CD 工具、代码检查工具、自动化测试工具等;
-
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. Rubocop 风格检测:对 .rb 后缀的文件进行入库,检测是否符合规范
-
2. 密钥检测:检测文件中是否发生了密码的泄露
当我们在 commit 时,就会运行这两个命令,检测提交的代码内容。
检测上图这段糟糕的的代码时,看到执行钩子 pre-commit 后的效果:
从而这段代码报错了,阻止 commit 的提交。
发现这些问题之后,就可以直接在本地去修复了,不用等待 CI/CD 时间;修复完再次提交,就成功了,可以看到 CI/CD 正常运行,让 CI/CD 在
测试期间也能正常通过,效率就大大提高了。
除了这些内容,我们还会进行一些常规检测,比如在 Lefthook 配置里,有一个叫 Ruby 代码风格检测工具 Rubocop,有一些命令可以修复大部分
错误内容,我们也可以加入一些自定义命令,如出现问题,自动修复并推送到服务后,给钉钉发送信息等。
极狐GitLab 中,大概有十几个 Lefthook 命令,在开发过程中自动发现常见问题并解决。
总结
很多时候,造成效率低下的原因,是发现问题的时机太晚,Git Hook 在本地就能帮助我们解决代码规范问题、代码安全问题,并通过自定义脚本
内容来自动执行,减少CI/CD、Code Review 时间,整体提升开发效率。