Geek专栏：Gitlab升级日记:12.5.6
本帖最后由 lou 于 2020-4-27 11:28 编辑Geek专栏：Gitlab升级日记:12.5.6
今天Geek专栏为大家带来
乐聚研发部黄怀贤的
“Gitlab升级日记:12.5.6”
什么是 Gitlab?
[*]https://about.gitlab.com/
[*]官方版本升级记录
(https://gitlab.com/gitlab-org/gi ... master/CHANGELOG.md)
我选择 Gitlab 的初衷
一个好的项目管理方法，项目推进的过程中所有的结果都是被详细记录，统计。同时最好这些记录都应该是必须的行为，而不是额外的工作。比如每周写周报，这种就没必要。
详细的历史记录需要有一个平台来记录。以前我使用过 Redmine, 这也是一个优秀的工单管理系统。但 Redmine 并不能和代码以及文档进行深度的交互。使用 Redmine 来管理项目的时候，只能先手动合并代码，再手动关闭工单。或者顺序反过来，不管如何，这样做总是繁琐的。在以前我只管理 0-5 个人的小团队的时候,勤快一点基本上是没有任何问题的。但是随着人员的增多，项目的变化，如果想要及时的确认开发完成的代码或者文档(我们是一个特别注重开发文档的团队), 仍然使用 redmine 几乎会用掉我所有的时间。做为一个程序员，我肯定不会让这件事情发生。而且一个优秀的程序员，必定不能是勤快的。勤快必然导致思维的懒惰。
所以我重新调研了平台，对新的平台设定了一些要求。其实主要还是对标 Github。
1. 代码仓库和工单紧密结合，当代码完成的时候，工单也应该要自动关闭。
2. 文档和工单紧密结合，其实某种程度上来说，文档和代码的意义是相同的。
3. 不可修改的历史记录，这一条主要是为了消灭在产品开发的过程为了确定哪个需求是什么时候提出的，什么时候改动的，怎么确认的，这些事情在传统的管理方式中特别费时间。又或者一刀切，不管文档，像一群无头无脑的苍蝇一样混沌地做完项目。
4. 提供详细的 API ，可以实现一些自动化的 Bot。比如，超期提醒，工单活跃程度降低提醒。
5. 规则应该合约化，自动化。不能期望每个人都时刻按照规则做事，但是平台应该能检测出不按规则执行，浪费其他人时间的事情。
所以我从修改工单的标题，评论为不可编辑开始，进行了粗糙的改造。后来慢慢的同步升级，就变成了维护一个单独的分支。不过这并不是硬分叉，我只是在每次 Gitlab 升级的时候把我的修改合并上去而已。我主要还是使用了整个社区的工作成果。目前改动比较少，基本上没遇到过需要很大工作量才能同步的问题。并且核心的功能我并不会改动，这样就会变成硬分叉。涉及核心的功能，比如代码评审，我使用 API + Bot 做了一个外部流程。
升级日记的由来
维护我自己的gitlab 分支已经有一段时间了，项目地址(https://github.com/carlos-wong/gitlab-ce-carlos)。
我的初衷是: 提供更严格的开发流程，以及不可修改历史记录。更严肃的工程实践。
因为在实际的项目管理中，你其实不能信任任何人，包括自己 :)。你只能信任不可修改的历史记录， 比如GIT(https://git-scm.com/)。所以我从一开始只是对 UI 做简单的修改，去掉编辑 Comment 的按钮。慢慢随着项目的发展，应用场景的复杂化，我开始尝试进行更复杂的修改。
因为我完全不会Ruby ，所以只是修改任何一个小功能，对我来说都算是复杂的修改。
随着版本功能的完善，一些朋友在开始在使用我定制的版本。所以应该有一个文档来记录改动的东西了。
这个版本我都做了什么?
目前为止最重要的修改
仅仅是在页面上去掉对应的按钮，其实只能用来忽悠一下小白和产品经理。因为通过 API 其实也是能进行操作的，只不过 API 的调用稍稍有点门槛。随着团队小伙伴们对平台的熟悉，他们开始尝试调戏这个平台了。所以其实是因为不得已和为了防范风险，我要从根源上限制操作。即使有用户想要通过 API 操作内容, 如果在平台上没有给与他们正确的权限，他也不能操作。从原理上解决问题，才是一个优秀的程序员。@nofeetbird(https://github.com/nofeetbirds) :)
所以经过一些尝试之后，我弄明白了 Gitlab 是如何管理用户权限的。所以我就对 Gitlab 的权限体系进行了为所欲为的修改，哈哈。
结合 12.5.6 ，我自己做出的修改
首先Maintainer 的责任很大，所以他应该有确认工单是否完成，是否调整工单截止时间，重新分配工单的权利。
Developer 的责任有限，所以要限制他们的某些行为。比如自行关闭工单，调整工单的截止时间。
Developer 以上才能访问项目的文档和源码，因为这些已经涉及到保密信息。
谁也不能修改平台上的记录，包括平台的管理员。
实现方法
1. 涉及权限规则代码是存在哪里？
1./app/policies/project_policy.rb
2. 权限是如何描述的？
在 GitLab中，每个项目有几个基本的角色: Guest,Reporter,Developer,Maintainer。权限从低到高，责任也是从小到大。
Guest 基本上来跟进项目,并且不对项目进行实际推动的人。
Reporter 项目问题的发现人，一般是测试人员。不过在我们的体系里面，测试发现的问题一般都和源代码的项目分开放置。
Developer 项目的实际执行者，可能是开发人员，提交代码，提交相关资料。也可能是产品相关，提交需求文档。
Maintainer 项目的责任人，负责确认每一件事情的完成情况。以及控制项目往正确的方向发展。
在源文件的代码中,以 Developer 的权限声明来举例:
1rule { can?(:developer_access) }.policy do
2 enable :read_merge_request
3 enable :download_code
4end
5
6rule { can?(:reporter_access) }.policy do
7 enable :admin_issue
8end
以上是一段Ruby 代码，但是其实你不需要懂 Ruby 的代码也能看明白。enable 代表允许对应的权限，: 后面声明的是对应权限的名称。当然 :value 在 Ruby 里应该是一个语法糖，可能是声明常量或者字符串。好的代码是不需要注释的，所以看这上面大部分的描述都能猜到功能。比如downlaod_code 代表是否允许下载源代码。
找到了以上的代码，你就能做一些基本的修改。比如 :read_merge_request 这个权限代表可以访问 Merge Request，在官方的版本上只要是 Reporter 以上的权限就可以访问源码。我认为不合适，大部分人在分配的时候都是直觉的认为只有从 Developer 以上才能访问源代码。
这只是定制的第一步，因为这些权限的设定并不是对应着某一个功能点，而是对应着一类功能点。
比如:enable :admin_issue, 代表拥有该权限的角色能够设置工单的基本信息。比如分配工单，更新工单的标签，设定工单的截止时间。
结合我自己的想法，我需要给 Reporter 修改工单的权限，因为需要 Reporter 给工单分配标签来对工单进行分类。除了分配工单和设定工单的截止时间, 因为这是 Maintainer 的责任和权利。
3. 是否可以增加一些新的权限？比如重新分配工单？
嗯，只能打开我的Emacs 开始从代码上下手了。
首先，我看了一下enable :admin_issue 都在哪里用到。
- `app/services/issuable_base_service.rb` 这里面的 `filter_params` 函数使用了这个权限的定义
- `ability_name = :"admin_#{issuable.to_ability_name}"` 构造了访问的权限
-` unless can?(current_user, ability_name, issuable)` 用来判断用户是否拥有对应的权限，如果没有则清空操作工单的参数
1unless can?(current_user, ability_name, issuable)
2 params.delete(:milestone_id)
3 params.delete(:labels)
4 params.delete(:add_label_ids)
5 params.delete(:remove_label_ids)
6 params.delete(:label_ids)
7 params.delete(:assignee_ids)
8 params.delete(:assignee_id)
9 params.delete(:canonical_issue_id)
10 params.delete(:project)
11 params.delete(:discussion_locked)
12end
虽然我不会Ruby 但是还是分析了一下代码。所以如果我想细化权限，我只要在./app/policies/project_policy.rb 中声明一个新的权限，比如 :assignee_issue。接着只需要在app/services/issuable_base_service.rb 根据我的理解简单的实现一下代码。
1unless can?(current_user, :assignee_issue, issuable)
2 params.delete(:assignee_ids)
3 params.delete(:assignee_id)
4end
以上的代码意思是:如果对应的用户没有 :assignee_issue 的权限，那么这段代码就会清空对应的 assignee 数据。
4. 查缺补漏
还记得 ability_name = :"admin_#{issuable.to_ability_name}" 这个构造吗？为何不是直接声明为 :admin_issue? 因为Merege Request 也是使用了同一个函数啊。所以我上面的实现引发了一个 Bug, 限制了 Developer 及以下的角色不能重新分配工单，但是也限制了他们不能在 Merge Request 中分配给代码审核机器人。嗯，一个机器人公司，主要就是做机器人嘛。
知道了这个问题之后，我增加了一些代码，不过其实还不够优雅。但是时间有限，先完成功能再说。
1if ability_name == :admin_issue
2 unless can?(current_user, :assignee_issue, issuable)
3 params.delete(:assignee_ids)
4 params.delete(:assignee_id)
5 end
6end
以上的代码增加了一个前提，只有在更新工单的时候才会使用 :assignee_issue 的检查逻辑。
5. 总结
我的分支的发布节奏，基本上是随着 GitLab 的开发周期。站在巨人的肩膀上，同时所有的内容开源，所以并没有损害社区。
软件开发工作的魅力，是对自己使用工具的为所欲为。能修改 GitLab 来符合自己的需求，总比生搬硬套的使用 GitLab 流程来进行项目管理要好。可能我的管理方法不够完善，但至少是符合实际情况的，能被现在团队的人掌握的。
有可能反复的修改之后我所有的修改都撤销了，最后直接使用 GitLab 的官方版本。没关系，至少现在乐在其中, 并且符合实际。
这是修改的代码:Diff (https://github.com/carlos-wong/g ... 6...carlos/12.5.6.5)
页:
[1]