基于GitLab的研发工作流
本文工作流模式，是我担任
LIZI UI Design团队 Leader 时，基于 GitLab 的工具集，创建的一套标准的研发工作流。当前文档是对这套工作流的拆解和说明。
背景
由于团队成员分属不同业务线，日常碰面、交流的机会比较少，不能用早会、日报等普通的项目管理方式，对项目研发进度进行把控，所以需要一种全新的管理模式。
主要的痛点有：
- 项目的研发目标、里程碑不明确
- 任务的分解不清晰
- 团队成员之间无法获知对方目前的研发状态
- 团队成员之间协作，缺乏信息记录
基于以上痛点，选择了 GitLab 提供的工具集，来一一解决。
接下来，开始这套工作流的讲解。
关键要素说明
确定项目的里程碑
小组成员，通过开会讨论，确定一个周期内的目标，包括有哪些交付物，需要的研发时长，再由此反推，确定好相应的里程碑。
进入 GitLab 的小组项目（以后的语境，均在此项目下，后续不进行累述），打开 Milestones 进行里程碑设置。
如下图所示，设置
- 里程碑代号（Title）
- 工作内容描述（Description）
- 开始日期（Start Date）
- 截止日期（Due Date）
确定信息标签
标签分类
主要的信息标签类别有：
- 待准入
- 待认领
- Doing
- 待 review
- 待关闭
- developer:名字
- reviewer:名字
设置
进入 Labels 设置页面，点击 New Label 按钮进行创建即可。
看板的设置
看板的作用是可以清晰地、透明化地体现当前项目的进度情况和研发人员的工作状态。
阶段说明
如图所示，看板的阶段前后顺序依次为：
- Open （默认的打开阶段）
- 待准入
- 待认领
- Doing
- 待 Review
- 待关闭
- Closed （默认的关闭阶段）
设置
进入 Boards 界面，可以选择 Create new board 创建新的看板。
并通过 Add List 按钮，添加新的看板阶段。
Issue 的设置
Issue 说明
如上图所示，Issue 的信息有：
- 任务名称（Title）
- 任务的工作内容（Description）
- 任务的执行者（Assignee）
- 任务所属的里程碑（Milestone）
- 任务当前的状态（Labels）
- 任务的截止日期（Due date）
其中，Assigness 的设置，可以在该 Issue 改变的时候，让任务执行者及时收到邮件通知。
另外，在 Description 中输入 /estimate（估时） 和 /spend（耗时） 进行工时的记录。
任务评估时长示例
如图，输入估时后，在 Issue 的信息面板中，Time tracking 会有信息的展示。
任务消耗时长示例
如图，输入任务耗时后，在 Issue 的信息面板中，Time tracking 会根据任务估时和当前的消耗时长，进行百分比的进度展示。
任务工作流讲解
初始任务
通过 New Issue 的方式，将任务的信息记录到 Issue 中，并打上信息标签待准入。
经过团队成员确认后（可通过开会的方式，集中确认），将该 Issue，通过看板面，移动到待认领阶段。
并且，为该 Issue 打上 Milestone（里程碑）的标记，正式确认当前任务所属的里程碑。
认领任务
在认领阶段的任务，团队成员只要将该 Issue 打上 developer：名字的标签，即可完成认领。
确定任务的工时信息和开发周期
需要操作以下 3 个步骤：
- 设置 Assignee 为自己，方便接收邮件提醒
- 设置 Due date（截止日期），大概预估任务的完成日期
- 通过 Description 评论，设置任务的估时和耗时
如下图所示，操作完成后的 Issue 面板信息。
另外，如果想要利用 GitLab 的 To Do 功能，可以在该 Issue 面板的最上方，点击 Add To Do 按钮，即可。
任务状态改变
任务状态的改变，都是通过看板，对 Issue 进行移动，来完成更改的。
比如，当前的任务正在编码中，就将 Issue 移动到 Doing 阶段。
具体如下图所示：
Review 阶段
改变 Issue 状态
当任务编码完成后，Issue 移动到待 Review 阶段。
这个时候，可以由 Issue 的研发者去找团队其他成员进行代码 review，也可以由其他成员，主动进行 review。
review 的人员，需要将该 Issue 打上 reviewer:名字 的标签，表示自己负责当前任务的 review。
打标签后，如下图所示：
提交 MR
另外，需要研发者发起 Merge Request 请求，将 feature-**分支的代码，合并到对应的 dev-**分支。
如上图所示，需要做以下几件事：
- 确定好要合并的分支
- 填写合并的信息（Title）
- 在 Description 中，输入 #，会有相应的提示，选择对应的 Issue，关联到当前的 MR
- 设置好 Assignee 和 Milestone
代码分支合并
负责 review 的人员，在 review 完代码后，对 MR 请求进行 resolve，合并进 release 分支。
然后，将看板中的 Issue 移动到待关闭阶段。
需要注意的地方：当 feature 分支的代码，与要合并的 dev 分支产生冲突时，需要研发在本地解决冲突，并 push 到远程的 feature 分支，才可以合并。
版本发布
所有当前里程碑的任务完成后，将 dev-***分支的代码合并到 dev 主分支，再由 dev 分支合并到 master 分支和 release 分支，并进行版本发布操作。
然后，将看板中，待关闭阶段的 Issue 移动到 Closed 阶段。
最近笔者在整理第一本电子书书稿《前端面试手册》，有兴趣的同学可以关注下～
喜欢我文章的朋友，可以通过以下方式关注我：
- 「star」 或 「watch」 我的GitHub blog - RSS订阅我的个人博客：王先生的基地
