微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

Douban CODE 豆瓣代码托管系统

程序名称:Douban CODE

授权协议: BSD

操作系统: Linux

开发语言: Python

Douban CODE 介绍

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

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 系统的奖励机制主要有积分和勋章这两个部分。积分的规则主要就两个:

  1. 提交的 PR 被 merge,增加 100 点积分

  2. 提交的 PR 被评论增加 5 点积分

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

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

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

CODE 上没有设置惩罚机制。

测试

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

Douban CODE 官网

http://douban-code.github.io/

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐