基于Gitlab的Code Review最佳实践

Posted by 刘勇(lyonger) on 2020-07-09

基于Gitlab的Code Review最佳实践

环境说明

  • 本文提到的社区版本和企业版本信息如下:
1
2
3
4
社区版本:GitLab Community Edition 11.11.4
企业版本:GitLab Enterprise Edition 12.6.7

注意:本文中有注明企业版(Starter)才支持的地方代表只有企业版(Starter)才支持。否则默认就是社区版也支持该特性。企业版的收费标准请参考官网:https://about.gitlab.com/pricing

Git Flow简介

image

  • 经典的git flow图中,有Master、Hotfix、Release、Develop、Feature等分支。每个分支的作用各不相同。各个分支的主要功能如下:
分支名 功能
Master master分支存储了正式发布的历史版本,是一个功能完整且随时可以发布到线上进行部署到可用分支。基于tag进行标记,方便快速回退。
Hotfix Hotfix分支是用来修复线上bug,快速打补丁用的。该分支是基于线上master分支的tag fork而来,bug修复完成后,该分支需合并到master分支和develop分支。
Release Release是一个发布分支。从这个时间点开始,develop分支继续合并新功能,但新功能不再合并到该分支。在该分支上可以有一些bugfix,当然bugfix也要同步合并到develop分支中。一旦所有工作都准备好,release分支合并到master上,并在master上打一个tag,标记为版本号。
使用专门的发布分支,可以使团队成员在完善当前发布版本的同时也能基于develop分支继续开发新功能。在实际开发过程中,我们将Release分支和Master分支合并成了一个Master分支,每周的版本发布是基于Master发布的。
Develop Develop分支作为功能的集成分支。后续的版本发布,feature新功能开发都是基于这个分支fork进行。
Feature Feature分支则是功能分支,使用develop分支作为父分支。当新功能开发完成后合并到develop分支。Feature分支不应该直接合并到master分支上。

Gitlab Code Review方式

  • 一共有2种常见的方式来进行gitlabcode review,本文主要介绍 远程方式的使用。
    • **本地方式:**在本地将源分支(Source branch)代码合并到目标分支(Target branch),然后Push到远程的目标分支(Target branch)

    • 远程方式: 将源分支(Source branch) Push到远端,然后在GitLab前端指定目标分支(Target branch)发起Merge Request,对目标分支(Target branch)拥有Push权限的用户执行Merge操作,完成合并。

Gitlab Code Review配置

  • Code Review执行之前,进行一些合理的配置会有事半功倍的效果,下面我们来谈谈有助于Code Review常见功能。

Approvals与Merge Request定制功能

  • 可对Merge Request进行定制,如下图,要求MR可点击合并的条件是:pipeline必须返回成功,同时所有discussions已被标记为resolved。其中默认删除源分支的功能只有企业版(Starter)才支持。
    image
  • 关于审核员规则(该功能只有企业版才支持),这里推荐按照团队的情况进行定制:一种是核心成员,经验丰富,对成员代码把关;另一种是,新人团队,随机抽取,互相监督,互相学习。
    image

Issue与Merge Request的模版功能

  • 在开发流程比较固定的情况下,我们可以对issueMerge Request的内容格式进行模版化,如下图,我们以code_review/project1这个repo为例,在仓库根目录下新增了.gitlab/issue_templates/Issue.md.gitlab/merge_request_templates/Merge_Request.md两个文件,分别代表设置issueMerge Request的模版内容。详细说明可参考官方说明
    image
  • issue的模版效果如下图所示:
    image
  • Merge Request的模版效果如下图所示:
    image

Issue与Merge Request的联动功能

  • 当提交到master默认分支时,gitlab支持提交信息带上:关键词 + issue编号来联动issue(注意关键字后面必须跟上一个空格)。常见的关键字有:fix/fixes/fixed、close/closes/closed、resolve/resolves/resolvedissue编号可以参考下图:
    image

案例参考

  • 下图为实际的操作案例
    image
  • Merge Request联动issue的界面。
    image
  • issue里面联动Merge Request的界面。
    image

Gitlab的Code Quality功能

  • 我们可以利用开源的Code Climate Engines工具,对仓库代码进行质量检查。Code Climate Engines可以免费使用,但是reportmr界面的report展示需要企业版(Starter)才支持。具体说明可参考官方文档,要使用该功能,需要配置好gitlab-runnerDocker-in-Docker模式,其中gitlab-runnerconfig.toml配置可参考如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[[runners]]
name = "gitlab_runner_name"
url = "https://git-test.xxx.com/"
token = "your_token"
executor = "docker"
[runners.custom_build_dir]
[runners.docker]
tls_verify = false
image = "docker:stable"
privileged = true # 必须打开特权模式
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
  • 对应的.gitlab-ci.yml配置可参考如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
code_quality:
stage: check
tags:
- codequality
image: registry.test.com/library/debian_ci
allow_failure: false
services:
- name: docker:stable-dind
alias: docker-codequality
variables:
DOCKER_TLS_CERTDIR: ""
DOCKER_HOST: "tcp://docker-codequality:2375"
DOCKERHUB_URL: "registry.test.com"
GIT_LFS_SKIP_SMUDGE: "1"
AUTH_TOKEN_TTL: "1800"
before_script:
- |
if ! [ -f .codeclimate.yml -o -f .codeclimate.json ] ; then
cp .gitlab/ci/codeclimate/.codeclimate.yml ./
fi
- |
if ! [ -f tox.ini ] ; then # pep8
cp .gitlab/ci/codeclimate/tox.ini ./
fi
- |
if ! [ -f .pylintrc ] ; then
cp .gitlab/ci/codeclimate/.pylintrc ./
fi
- |
if ! [ -f .cppcheck-suppressions ] ; then
cp .gitlab/ci/codeclimate/.cppcheck-suppressions ./
fi
- |
AUTH_TOKEN=`python $PWD/.gitlab/ci/dockerhub/get_token.py`
docker login -u "$AUTH_USER" -p "$AUTH_TOKEN" "$DOCKERHUB_URL"
docker run --env CFG="$(cat /root/.docker/config.json)" \
--volume /root/.docker:/root/.docker \
alpine sh -c 'echo "$CFG" > /root/.docker/config.json'
script:
- |
if ! docker info &>/dev/null; then
if [ -z "$DOCKER_HOST" -a "$KUBERNETES_PORT" ]; then
export DOCKER_HOST='tcp://localhost:2375'
fi
fi
- docker run --env SOURCE_CODE="$PWD"
--env ENGINE_MEMORY_LIMIT_BYTES=4000000000
--volume "$PWD":/code
--volume /var/run/docker.sock:/var/run/docker.sock
--volume /root/.docker:/root/.docker
"$DOCKERHUB_URL/test/codequality:12-3-stable" /code
- |
if [ -f gl-code-quality-report.json ] ; then
REPORT=$(head -n 1 gl-code-quality-report.json)
if [ "$REPORT" != '[]' ] ; then
exit 1
fi
fi
after_script:
- docker logout "$DOCKERHUB_URL"
artifacts:
reports:
codequality: gl-code-quality-report.json
paths: [gl-code-quality-report.json]
when: on_failure
expire_in: 1 week
only:
refs:
- merge_requests
changes:
- .gitlab/ci/Code-Quality.gitlab-ci.yml
- .gitlab/ci/codeclimate/*
- Client/Content/Scripts/**/*.py
- Server/Logic/**/*.py
- Server/GameCpp/GameCore/**/*.{cpp,h}
except:
variables:
- $CODE_QUALITY_DISABLED

empty-report:
stage: check
tags:
- docker-dind
image: registry.test.com/test/alpine:3.11
variables:
GIT_LFS_SKIP_SMUDGE: "1"
GIT_SUBMODULE_STRATEGY: none
GIT_STRATEGY: none
script:
- echo '[]' > gl-code-quality-report.json
artifacts:
reports:
codequality: gl-code-quality-report.json
expire_in: 1 week
only:
refs:
- master
  • 这里需要注意的是,当检查的代码文件数较多时,需要根据情况适当提高ENGINE_MEMORY_LIMIT_BYTES的值,否则会因为内存不足检查失败。同时gl-code-quality-report依赖上次master分支是否有diff而进行展示,故首次使用时,需触发下面的empty-report这个stage,上传一个空的gl-code-quality-report.json文件。

  • 上传以后,在MR的界面,可以看到类似如下的界面,代表Code Quality功能启用成功。
    image

Gitlab Code Review实践

  • 我们以一个测试项目为例进行简单的Code Review说明。

第一步:选择源目标分支

  • 如下图,选择源分支和目标分支,新建MR:
    image

第二步:设置MR相关参数

  • 注意下面的Merge request dependenciesApproval rules只有企业版(Starter)才支持。
    image

第三步:开始review

  • 开始code review,多人进行discusscomment,其中多人Finish review的功能只有企业版(Starter)才支持。如下图:
    image

第四步:审批解决discuss

  • discussions未解决时,无法点击Merge按钮。当所有discussions已经解决,并且pipeline执行成功,approve批准以后,才可点击执行。下图为了演示方便,我取消了本次的approve
    image

第五步:解决合并冲突

  • 如果合并过程产生了冲突,如下图所示,提示你有2种方式来处理。一种是直接在web前端界面进行修改。另外一种是在本地进行修改。解决冲突时需要拉上团队里的其他成员一起讨论,留下最终需要的内容进行提交即可
    image
  • 这里我为了演示方便,我选择在前端上直接修改冲突,点击Resolve conflicts,出现如下界面,按照图中三个步骤操作即可。
    image

第六步:融入目标分支

  • discuss已经解决、pipeline执行成功、Approval审批完成、Conflicts已经解决的时候,可以看到Merge按钮为绿色,最终点击MR融入目标分支。
    image

建议与总结

  • 选择社区版本(CE)还是企业版(Starter),取决于业务的需求。如果业务的Code Review过程强烈需要多人审批(approval)、多人Finish reviewCode Quality的report在MR展示等功能,则优先考虑企业版,否则社区版本做也是一个不错的选择。


支付宝打赏 微信打赏

赞赏一下