CODE－豆瓣代码托管系统

weixin_34354945

于 2015-12-09 09:45:00 发布

阅读量100

点赞数

原文链接：https://my.oschina.net/u/2306127/blog/541233

版权

2019独角兽企业重金招聘Python工程师标准>>>

Douban CODE 是豆瓣开发的一个基于 git 版本控制系统的协作平台。

代码访问：https://github.com/douban/code

CODE —— C: Community O: Original D: Developer E: Eldamar

目前 CODE 仅开放了一个框架，支持：

clone & push project
create project
create user

准备环境

MySQL
Memcached
Python >= 2.7
pip >= 1.4.1
virtualenv
git

CODE 为每个项目设置了三个角色，分为 owner（有全部权限）、committer（有 push 和 merge 权限）、member。review 机制根据项目的不同设置了不同的规则，如产品线级别的、需要对外发布的项目，基础库等项目都需要经过严格的 review，如东西团队对 review 设置了如下规则：

尊重他人，就事论事，对事不对人，毕竟每个人都写过烂代码；
PR 中的每一个 commit log 都应该可以和代码对应，方便 review；
尽量不要发太大的 PR，以免引起 reviewer 的恐慌；
建议保证一个 PR 的粒度和专注，最好不要出现一个 PR 里又有重构又加新 feature 的情况，同样容易引起 reviewer 的恐慌；
提 PR 之前请确保在本地或测试环境一切正常；
reviewee 如果接受 reviewer 提出的修改意见，需要在修改提交以后知晓 reviewer，常见的做法可以是在 review comment 处回复（并带 commit 链接）；
评论中至少出现一个 lgtm 且保证 ci 通过之后 PR 才可以被合并；（注：lgtm 即 looks good to me 的缩写）
PR 合并者与提交者不能是同一个人；
PR 需从一个特定分支（分支的名字尽量能表达代码的功能）发往上游的 master 分支；
Model 的部分，如不紧急需要unittest；
Web 的部分，如不紧急需要webtest；
PR 合并后如引起 bug 或功能异常，并经查确为此 PR 引起，提交者需请全组攻城湿喝饮料或吃冰棍（由被请者决定）；
将 fork 的仓库与上游同步时，应使用 git fetch upstream && git rebase upstream/master （或 code sync -r ），而不是 git merge 或 code sync （这里code是指面向 CODE 系统的一个命令行工具），以保持清晰的提交历史，并防止覆盖他人的修改；
注意安全问题，对于 SQL 拼字符串，模版中有 |n 的，以及处理用户输入等地方都需要仔细review，更多请参考 Web 安全开发指南

对于松散或娱乐性项目、小工具项目，并不会那么严格的 review，这也取决于 owner 自己，他可以借这个项目寻找到一位导师，来帮助他进行 review：

举一个具体的例子，例如东西团队的 Android 版本的开发，实际上最开始只是团队内部的一些成员想学习 Android 开发自发组织起来的，但一开始就找了移动组的同学来随时帮助 review。

对于 CODE 项目本身，所有工程师都可以向 CODE 上的任意项目提 PR，也都可以是CODE 的 reviewer，同时所有工程师的代码都需要经过 review 才会被 merge 到 master 分支。

发展到现在，豆瓣的 review 基本上都是自发，很少遇到需要 review 的代码堆积的情况。代码讨论区里据说时不时会出现美女图，这可能是刺激工程师们去 review 的因素之一；另外，CODE 系统本身也有奖励机制，鼓励大家去评论别人的代码。

CODE 系统的奖励机制主要有积分和勋章这两个部分。积分的规则主要就两个：

提交的 PR 被 merge，增加 100 点积分
提交的 PR 被评论，增加 5 点积分

目的就是鼓励多发 PR。一般来说，小 PR 要好过大 PR，不过有时候开发任务比较紧的时候，发出比较大的 PR 也是在所难免。

勋章系统在 CODE 早期阶段就做了进去，早期的奖励规则主要跟代码提交相关，例如给开源项目发过 Patch 并被 merge 会有相应的徽章。现在 CODE 团队对勋章系统有一些新的规划：

目前希望徽章系统可以独立出来，只是一套独立的API，任何人任何产品线都可以去设置自己的奖励规则，让这种奖励变成不是一种公司行为，而是更小的行为。例如 antispam 组，可能就会有百人斩徽章，这个对于其他组可能就不是那么必要，当然如果你跨界帮助过 antispam 组，那么也有可能会获得这个徽章。

CODE 上没有设置惩罚机制。

测试

相比 Github，CODE 有一些非常实用的地方，比如在提交代码入库之前可以先在 CI 里面完成自动测试，reviewer 可以直接看到代码测试是通过（绿色）还是失败（红色）；代码完成 merge 之后还可以通过 DAE 直接往线上部署。持续集成、自动测试、监控、部署这些都是独立系统，与 CODE 都是靠 API 来进行交互。

转载于:https://my.oschina.net/u/2306127/blog/541233