GitLab 是一个类似于 GitHub 的开源源码托管服务,它除了提供基于 git 的基本代码托管服务外。还具备很多与软件开发协作相关的其他功能。比如 issues、Merge Requests 等。
利用 GitLab 提供的这些功能,我们可以实践一些简单的项目管理和协作流程。这套流程借鉴于很多成功的开源项目,非常适合在小型开发团队里面使用。
GitLab issues 类似于“工单系统”,是一个发布项目相关信息的地方。项目的所有成员都可以创建新的 issue,其他成员可以在 issue 下进行相关的讨论。
issues 本身是一个非常简单的功能,但是如果配合 “标签”、“里程碑” 等功能一起使用,就可以承担起一定的项目管理工作。
在项目的开发过程中,我们会碰到很多新的需求、软件 bug 等。这些需求与 bug ,就是 issue 最大的来源,它们都可以作为 issue 录入到项目的 issues 中。
因为 issue 的录入门槛很低,鼓励项目成员录入 issue 后,项目很容易就会出现大量的 issues。所以我们应该严格控制每个 issue 的内容质量,确保其他人可以通过这个 issue 获取足够多的信息,提高沟通效率。
不光是和需求和 bug,任何和项目有关的内容都可以录入到 issue 中。
编写优秀的“需求” issue
如果你要录入一个需求类的 issue,最好在内容主体中包含下面这些内容:
编写优秀的“bug” issue
如果你要录入一个 bug issue,最好在内容主体中包含下面这些内容:
当 issue 被创建后,应该等待项目的 owner (owner 指项目的所有者,是对项目各方面都比较了解的人,可以为多个人) 对 issue 进行 Review。
Review 时,如果 owner 觉得这个 issue 满足下面的任意条件:
则应该在评论中说明相关情况,并关闭该 issue。如果经过上面的过滤后,觉得 issue 应该被继续跟进,那就应该为它打上标签,方便之后的筛选、排期等工作。
“标签”是 issue 的核心特性,为了更好的使用它,我建议采用 “{type}/{value}” 这样的二维标签来取代传统的 “{value}” 单维标签,下面是一些常用的 issue 标签:
优先级:priority
优先级(priority)是最重要的标签之一。它直接影响 bug 需要被响应的速度、或需求的具体排期。
类型:kind
kind(类别)表示 issue 属于哪种类型。
工作量:size
size(工作量)表示 issue 需要大约花费多少时间/精力,可以用来做简单的工作量评估参考。
领域/模块:area
area用于标记当前 issue 属于项目中的什么领域/模块。这个分类下的具体标签由项目本身决定。比如 area/apiserver、area/controller 等。给 issue 打上 area 标签后,项目不同模块的相关负责人可以更方便的找到自己负责的相关 issues。
GitLab 的标签是一个非常灵活的功能,在具体使用中,不必拘泥于上面列出来的这几种标签,可以根据当前项目特点随意调整。
当 issue 被创建、打上标签以后,就可以进行后续操作了。issue 的后续操作主要包括下面几种:
除了为 issue 打上标签以外,你还可以为 issue 绑定上 milestone(里程碑),来将 issue 与某些特定的项目节点关联起来。之后便可以在 milestones 页面查看每一个里程碑的进展。
和 labels 一样,里程碑也是一个十分灵活的功能,你可以根据项目需要建立不同的里程碑,比如:
使用 issue board(类似于敏捷开发中的“看板”),可以在一个页面看到当前处于不同阶段的所有 issues。这个功能非常适合站立晨会时使用。
随着项目越来越大,项目累积的 issue 也会越来越多。而这些 issue 中有很多已经失去它的价值。
所以,为了避免有价值的 issue 淹没在这些过时的信息当中,我们应该定期 Review 现有的 issues,关闭掉那些已经过时的 issues。
在 GitLab 上创建的项目,所有人都不应该直接往 master 分支推送代码。而是应该在其他分支(或者 fork 项目的分支)进行开发。并最终通过创建 Merge Request(类似 GitHub pull request)将代码合并到 master 分支。
基于 MR 的开发流程如下:
我们一般会用类似于 dev_piglei 这样的分支名称进行开发,遵循着 “开发” -> “push 并创建 MR” -> “开发” 这样的工作流程。
但是,因为一个分支是严格对应到一个 MR 的,当你在同一个分支上开发不同功能时,如果 MR 一直处于 open 状态,那这些不同功能都会被推送到同一个 MR 上,对 Review 过程产生困扰。
为了避免这种情况,最好为不同的功能项创建不同的分支并各自创建 MR,比如dev_feature_add_member、dev_feature_disabled_user。
在 git 工作流方面,git-flow workflow 是一个值得学习的内容
如果开发一些比较大的需求,我们通常会将他们一次实现完,然后作为一个大的 MR 来提交 Review。
但是如果每个 MR 过于复杂,会大大影响 Code Review 的效率。所以,如果你要实现一个比较复杂的特性,建议将它拆解为多个比较小的 MR 来依次提交。
假如,你要为网站的 feed 页面从零开始添加 redis 缓存功能。可能一开始想的提交这个大 MR:
添加基于 redis 的缓存模块并为 feed 页面添加缓存并主动过期
但这个 MR 里面包含了太多内容,会增加 Review 的难度。所以可以试着将这个功能拆解为下面三个更小的 MR:
添加基于缓存模块
为 feed 页面提供缓存,并主动过期
谨记:
超过 1000 行的代码改动 Review 起来非常困难