Douban CODE豆瓣代碼托管系統(tǒng)
Douban CODE 是豆瓣開發(fā)的一個基于 git 版本控制系統(tǒng)的協(xié)作平臺。
CODE —— C: Community O: Original D: Developer E: Eldamar
目前 CODE 僅開放了一個框架，支持：
clone & push project
create project
create user
準備環(huán)境
MySQL
Memcached
Python >= 2.7
pip >= 1.4.1
virtualenv
git
CODE 為每個項目設置了三個角色，分為 owner（有全部權限）、committer（有 push 和 merge 權限）、member。review 機制根據(jù)項目的不同設置了不同的規(guī)則，如產(chǎn)品線級別的、需要對外發(fā)布的項目，基礎庫等項目都需要經(jīng)過嚴格的 review，如東西團隊對 review 設置了如下規(guī)則：
尊重他人，就事論事，對事不對人，畢竟每個人都寫過爛代碼；
PR 中的每一個 commit log 都應該可以和代碼對應，方便 review；
盡量不要發(fā)太大的 PR，以免引起 reviewer 的恐慌；
建議保證一個 PR 的粒度和專注，最好不要出現(xiàn)一個 PR 里又有重構又加新 feature 的情況，同樣容易引起 reviewer 的恐慌；
提 PR 之前請確保在本地或測試環(huán)境一切正常；
reviewee 如果接受 reviewer 提出的修改意見，需要在修改提交以后知曉 reviewer，常見的做法可以是在 review comment 處回復（并帶 commit 鏈接）；
評論中至少出現(xiàn)一個 lgtm 且保證 ci 通過之后 PR 才可以被合并；（注：lgtm 即 looks good to me 的縮寫）
PR 合并者與提交者不能是同一個人；
PR 需從一個特定分支（分支的名字盡量能表達代碼的功能）發(fā)往上游的 master 分支；
Model 的部分，如不緊急需要unittest；
Web 的部分，如不緊急需要webtest；
PR 合并后如引起 bug 或功能異常，并經(jīng)查確為此 PR 引起，提交者需請全組攻城濕喝飲料或吃冰棍（由被請者決定）；
將 fork 的倉庫與上游同步時，應使用 git fetch upstream && git rebase upstream/master （或 code sync -r ），而不是 git merge 或 code sync （這里code是指面向 CODE 系統(tǒng)的一個命令行工具），以保持清晰的提交歷史，并防止覆蓋他人的修改；
注意安全問題，對于 SQL 拼字符串，模版中有 |n 的，以及處理用戶輸入等地方都需要仔細review，更多請參考 Web 安全開發(fā)指南
對于松散或娛樂性項目、小工具項目，并不會那么嚴格的 review，這也取決于 owner 自己，他可以借這個項目尋找到一位導師，來幫助他進行 review：
舉一個具體的例子，例如東西團隊的 Android 版本的開發(fā)，實際上最開始只是團隊內部的一些成員想學習 Android 開發(fā)自發(fā)組織起來的，但一開始就找了移動組的同學來隨時幫助 review。
對于 CODE 項目本身，所有工程師都可以向 CODE 上的任意項目提 PR，也都可以是CODE 的 reviewer，同時所有工程師的代碼都需要經(jīng)過 review 才會被 merge 到 master 分支。
發(fā)展到現(xiàn)在，豆瓣的 review 基本上都是自發(fā)，很少遇到需要 review 的代碼堆積的情況。代碼討論區(qū)里據(jù)說時不時會出現(xiàn)美女圖，這可能是刺激工程師們去 review 的因素之一；另外，CODE 系統(tǒng)本身也有獎勵機制，鼓勵大家去評論別人的代碼。
CODE 系統(tǒng)的獎勵機制主要有積分和勛章這兩個部分。積分的規(guī)則主要就兩個：
提交的 PR 被 merge，增加 100 點積分
提交的 PR 被評論，增加 5 點積分
目的就是鼓勵多發(fā) PR。一般來說，小 PR 要好過大 PR，不過有時候開發(fā)任務比較緊的時候，發(fā)出比較大的 PR 也是在所難免。
勛章系統(tǒng)在 CODE 早期階段就做了進去，早期的獎勵規(guī)則主要跟代碼提交相關，例如給開源項目發(fā)過 Patch 并被 merge 會有相應的徽章?，F(xiàn)在 CODE 團隊對勛章系統(tǒng)有一些新的規(guī)劃：
目前希望徽章系統(tǒng)可以獨立出來，只是一套獨立的API，任何人任何產(chǎn)品線都可以去設置自己的獎勵規(guī)則，讓這種獎勵變成不是一種公司行為，而是更小的行為。例如 antispam 組，可能就會有百人斬徽章，這個對于其他組可能就不是那么必要，當然如果你跨界幫助過 antispam 組，那么也有可能會獲得這個徽章。
CODE 上沒有設置懲罰機制。
測試
相比 Github，CODE 有一些非常實用的地方，比如在提交代碼入庫之前可以先在 CI 里面完成自動測試，reviewer 可以直接看到代碼測試是通過（綠色）還是失?。t色）；代碼完成 merge 之后還可以通過 DAE 直接往線上部署。持續(xù)集成、自動測試、監(jiān)控、部署這些都是獨立系統(tǒng)，與 CODE 都是靠 API 來進行交互。