3. Code Review 流程演示... 3

三、 IDE Merge Request 插件使用介绍... 10

1. IDEA 插件使用介绍... 10

a. GitLab Access Token. 10

b. JetBrains IDE GitLab插件使用... 11

c. 配置GitLab Server 12

d. Create Merge Request 13

e. Merge Request Manage. 16

f. Merge Request Diff 18

g. Merge Request Comments. 18

目前Lenovo Brain的开发、测试、部署及运行都是基于Kubernetes容器云技术栈。在经过一段时间的摸索和实践后，将基于容器云的Devops CI过程进行总结，并形成Code Review流程向导、CI过程等文档，期待能为在人工智能实验其它团队提供参考。本文档将从Gitlab Code Review机制、Workflow、配置说明、流程演示及插件五个方面进行阐述。

以往的经验表明，容器云DevOps从CI起步。CI持续集成是编码、构建的过程。但这仅仅是一个开发构建过程，都在开发端，是实现敏捷开发的一种方式，研发过程自动化，这也是我们考虑采用容器云和DevOps的一个因素。

一、 GitLab Code Review机制

在代码开发完成后，将已经过通过本地测试的本地个人源分支(Source branch)Push到远端的个人分支，然后在GitLab系统中指定目标分支（Target branch）发起Merge请求。请求发起后，对目标分支（Target branch）拥有Push权限的用户进行代码审查，审查通过后执行Merge操作，完成源代码分支合并。

也就是说，使用GitLab进行Code Review就是在分支合并环节发起Merge Request，然后Code Review完成后将代码合并到目标分支。

二、 GitLab Code Review 配置

1. 通用Git工作流说明

新项目创建后，从master分支创建develop分支。
开发人员从develop分支创建自己的feature分支进行开发。
master分支发生变更，需要从master分支合并到develop分支。
feature分支合并到对应的develop分支之前，需要从develop分支合并到feature。
feature分支合并到对应的develop分支之后，发布到测试环境进行测试。
develop分支在测试环境测试通过后，合并到release分支在预发布环境进行测试.
release分支在预发布环境验证通过后，合并到master分支并发布到生产环境。

图 1 通用Git工作流说明

表 1 代码分支名称约定

分支类型	名称格式	说明
Master	master	有且只有一个
Release	release-*	*可以是班车发布日期也可以是需求名称缩写，也可以根据需要只用一个release分支
Develop	develop-*	*通常是班车发布日期或者需求名称缩写
Feature	feature-{itcode}

2. Code Review 环节及工作流

在通用Git流程中，开发人员在Feature分支进行开发，开发完成后Merge到Develop分支进行测试。最适合做Code Review就是Feature分支合并到Develop分的环节(图2中标为红色部分)，即开发人员在Feature开发完成后，发起Code Review Merge Request 到Develop分支，拥有Master角色的用户具有代码Review审查权限，经审查通过后，代码可Merge到Develop分支。

图 2 Code Review在通用流程中的环节

3. Code Review 流程演示

本章节通过一个完整的实例来说明整个CI的CodeReview过程。使用的GitLab仓库相关配置以https://gitlab.lenovo.com为例。具体步骤如下：

a. GitLab新建仓库和创建分支

图 3 创建新的项目

图 4 创建新的分支

新建分支：

release(from master)

develop(from master)

feature-chenjie32(from develop)

建好之后如下状态

图 5 创建好分支的状态

b. Protected Branches 配置

为了保证必须以Merge的方式变更develop分支、release分支、以及master分支，我们需要对每个分支进行Push以及Merge权限进行设置。设置过程如下：

菜单->Settings->Repository 然后展开Protected Branches选项

图 6 设置权限入口

依次将develop和release设置protect，并设置merge和push权限

图 7 设置相应权限

设置好的权限如下图所示。

图 8 权限设置完成的示例

c. 变更Feature分支

在Gitlab系统中将代码分支切换到feature-chenjie32进行开发。为了演示方便，本问这里直接在网页上修改README.md文件，如图9所示。

图 9 修改README.md文件

修改完毕，填入相关注释后点击提交按钮，如图10所示。

图 10 提交修改文件修改

d. 提交Merge请求

修改后，在对应的分支commit上会出现请求Merge的按钮，如图11所示。如果开发者认定本次提交的代码需要Merge到目标分支（Develop）时，需要填写表单，发起Merge请求，如图12，13所示。表单中的各项内容如表2所示。

图 11 提交Merge请求

图 12 Merge请求表单内容（一）

图 13 Merge请求表单（二）

表 2 Merge表单项及说明

操作项/填写项	说明
Title	标题，没有特殊要求保持默认即可
Description	描述，需要将变更的需求描述清楚，最好附件Code Review要点
Assignee	分配到的人，被分配到的人将会收到邮件通知，跟Merge权限没有必然关系
Milestone	里程碑，如果没有可不选
Label	标签，如果没有可不选
Source branch	源分支，跟上一步骤选择一致，这里主要用于确认
Target branch	目标分支，跟上一步骤选择一致，这里主要用于确认

e. Merge操作

项目中每个用户都可以看到merge request请求，只不过按照之前的配置，只有Masters角色的成员才有Merge的权限，如图14所示。

图 14 Merge请求详情页

同时，也可以给用户发表评论，可以在这里进行交流，讨论代码问题等。

图 15 评论页面

拥有Merge权限的用户在合并代码前，必须保证需要合并的代码是审查过的。在Master角色点击Merge后，Develop分支即有了新增的内容，而其他两个分支Release和Master分支没有Merge，无此部分代码，如图16所示。

图 16 Merge后结果

三、 IDE Merge Request 插件使用介绍

前面介绍了通过GitLab网页创建Merge Request并发起Code Review，但作为开发人员，还是结合IDE来使用会更顺手，GitLab提供了相关的api，只要我们创建响应的token，就可以供IDE插件来访问GitLab，以便使用IDE代替在网页上操作。目前主流的开发IDE中，只有IntelliJ IDEA能够完整支持Gitlab Code Review流程。

1. IDEA 插件使用介绍

a. GitLab Access Token

首先需要申请一个访问Gitlab API 的Access Token。菜单：User Settings-> Access Tokens 进入Access Token添加页面，如图17所示。需要注意的是创建完成后，需要及时保存生成的token，否则一旦刷新或者重开页面，token就将不可见。

图 17 申请Access Token

表 3 Access Token表单项及说明

选项	说明
Name	名称，根据自己喜好来即可
Expires at	过期时间，最远可以选择到10年后，根据自己需要填写即可
Scopes	范围，这里选择api就够用了

b. JetBrains IDE GitLab插件使用

JetBrains提供了诸多IDE：IntelliJ IDEA、PyCharm、PhpStorm、WebStorm、RubyMide、AppCode、CLion、GoLand、DataGrip、Rider、Android Studio等等，如无意外，都适用GitLab插件。针对Code Review流程，安装以下两个插件即可：

Gitlab Projects：https://plugins.jetbrains.com/plugin/7975-gitlab-projects

Gitlab Integration：https://plugins.jetbrains.com/plugin/7319-gitlab-integration

安装GitLab插件过程如图18，19.：

Settings->Plugins 进入Plugins管理页。