有人實踐過 Phabricator 以及 Arcanist 作為 code review 的工具么？

12-27

我平時就經常實踐. 整個公司的code review就是使用這個.

具體說來, 由於我的project稍微有點特殊,所以我這一年在facebook工作的時候一直在用兩套Code Review工具: Facebook的Phabricator 和 Google的Gerrit (他們都是開源). 我覺得兩個工具都很快,很穩定,然後都有效地提供了code review必備的功能:比如比較任意兩個不同版本, 對任意一行代碼來寫評語, 以及可以很方便地導入和導出代碼到本地機器.

用了將近一年的時間,如果我要給自己的公司選一個工具的話,我會選擇Phabricator. 主要是覺得這個界面很乾凈, 然後配色非常好看, 整個感覺比Gerrit要現代化不少. 另外一個方便地地方,就是Gerrit上面只能看到版本做的修改,而無法直接展開整個文件(除非下載), 而這點Phabricator完成得比較好. 還有就是Phabricator上面可以發各種圖片,顯得氣氛比較輕鬆. 具體你可以在http://Phabricator.com上面註冊一個賬戶,然後去看看eprisetley的diff, 就可以大致了解這個工具的功能和特點.

最後要說的是: 這個工具現在已經開源, 並不屬於Facebook, 而且開發它的首席工程師也已經離開Facebook自己創業.

在加上 AladdinZ 張超在評論裡面說的亮點: (credit屬於他,而且的確也是我用後覺得有很大差別的地方)
1. Phabricator將所有文件的比較直接展開,然後放在一起,方便人閱讀. 而Gerrit只有一個文件列表,然後用戶需要點每一個文件,才能看到具體的修改;
2. admin的許可權設置問題.

另外我還想到一點Phabractor比較人性化的地方:
Phabricator還可以捆綁unit test和以及格式檢查和規範的工具(e.g. JSLint), 然後用戶在上傳diff的時候, phab會自動用新版本的代碼去跑unit tests,以及運行JSLint, 然後在code review裡面就可以看到unit tests有幾個failure和error,以及JSLint的報警信息. 對於Gerrit, 不知道能否類似配置一下.

從 12 年公司老東家成立創新產品團隊開始到目前，Phabircator 已經從只有我們團隊使用到現在老東家全面投入使用。剛開始由於是創新產品團隊，不用受制於公司大環境的束縛，可以自由發揮的空間更多。由於個人比較喜歡玩工具，比如 Trac 和 Redmine 以及 Bugfree 都用過很長時間（當然從來沒有覺得很滿意），正當總是不滿意的時候 Phabricator 進入了視線，經過一些使用和研究，我們決定將傳統的 Subversion + ReviewBoard + Jenkins 切換到 Git + Phabricator 的平台上，暫時拋棄了持續集成部分，輕裝簡從開始了我們新的工具時代。

Phabricator 最早是 Facebook 的內部審查工具，看過王淮的《打造 Facebook》都應該知道，Facebook 最厲害的工程師都需要進入工具部門去鍛煉深造，所以質量就不明覺歷了吧。據說後期 Phabricator 在 Facebook 資助下專心做這個，迭代和更新速度都很快，整體界面和 Facebook 的風格簡直是如出一轍（就覺得 Facebook 的傳統風格太像是工具了）。

作為資深使用用戶有資格發表點對使用 Phabricator 的一些看法：

首先，Phabricator 是基於 PHP + Mysql 的，但是配置起來也不麻煩。個人也曾經貢獻過一些 Bug fix，從代碼上來說 Phabricator 雖然不是我的風格，但風格和寫法上非常不錯。所有的開發都是面向 OOP，資源的管理是分離的很清楚的，配置的管理是多重的（資料庫，文件，默認）等等。高手寫的代碼都值得追隨和拜讀。所以，如果你在做 PHP 建議來讀一讀。

其次，傳統的概念上，項目、倉庫和任務都是以項目為主綁定在一起的。而在在 Phabricator，所有這些都不是耦合在一起的。項目就是項目，倉庫就是倉庫，任務就是任務。但所有的東西都是以項目作為線索連接在一起的。一個任務可以屬於多個項目，倉庫的 commit 和 review 只有在提交任務的時候，可以結合進去。如果要想更好的使用倉庫，比如自動 Review，審查 commit，還需要用到 Owners，根據配置，所有人會擁有倉庫的審查許可權，所有倉庫的提交也都有 Owners 來進行審核。這種鬆散的組合，想必和 Facebook 內部開放協作的項目態度是有關的，對於開放的團隊來說非常有好處。

再者，代碼倉庫的支持很完整。Git，Svn，HG 一個都不落下（什麼，你說 CVS，那是什麼）。對於倉庫，Phabricator 有很好的自動檢測和拉取機制，你推的代碼，很快它就能收到，根據你定製的規則去指派給相應的人去審核。除了可以審核，查看代碼也非常方便，甚至它本身支持了 ctags 的導入，如果你導入了 ctags ，在代碼中甚至可以用 IDE 中快速定位的方式去查找代碼源自哪裡？高亮自然就不用說了，沒有一種語言不支持的，估計新版本連自己的 Haske Lang 都支持。

然後，輔助工具也很豐富，對於開發之外的各種需求來說都可以滿足。比如文檔、圖片審查、倒計時、問答、代碼分享、投票、密鑰管理、日曆、聊天、文件共享簡直是費盡心思。文檔是代碼開發的重要部分，Phabricator 採用了自己編寫的 reMarkup 語法和Markdown 非常相似，但是多了表格，目錄索引，引用自有文件任務等功能，使用上很快就能進入，基本不會有什麼問題。簡單說說圖片審查，這塊是我最沒有想到的。不過也解決了一個我們設計的痛點。可以把設計稿提交上來給大家看，你我都可以圈圈點點，提交意見，最終定稿。否則，設計師這個跟開發同性質（需要被產品經理趕）的用戶只能上 Phabricator 看任務。其它的就不多說了，基本都是字面意思，如果你有用到最好，用不到也無所謂，只是輔助。

接著，要說下命令行。Phabricator 提供了個命令行叫 arc （Arcanist），總之很方便。它有幾個用處：操作數據（任務查看操作）；開發輔助（gitflow 工作流，查看提交的 diff，代碼檢查，執行單元測試）；輔助（文件分享下載、代碼分享，升級）等等。對於開發來說，命令行再熟悉不過，用好這個命令行可以少上 Web 界面去操作，對工作效率的提升簡直是大讚。

最後，Phabricator 很潮很自由。看看界面上的文字上如果你不去查查字典，估計有不少詞你都不認識，應該不少是出自希臘古語。不過可以通過配置關閉使用正常點的描述。在賬號系統支持上支持的很到位。Github、Facebook、Google 和公司內部的 LDAP 都能支持。Phabricator 的 API 是開放的，基於此你可以做出來很多符合自己需求的東西。Phabricator 也對郵件支持的也很到位，配置好收發郵件後，就可以像 Github 那樣使用郵件來進行工作流。

總之。如果你在挑選 Review 系統拿不定主意，看完就果斷入了吧。這套系統是免費的開源的。就先說這麼多。

我與樓上@趙戈戈以前是一個團隊的
不只是適用於開發，我們產品團隊也將pha用於產品文檔撰寫和項目進度管理
pha類似markdown的語法能夠很好的控制文檔格式，在線編輯模式又提高了產品與技術直接文檔信息同步的效率，如果很好的使用郵件訂閱的功能，重要文檔的修改都可以及時的告知每一個相關人員
同時，task式的任務指派模式能很好的整理產品需求，將以往Excel管理feature的模式在線化，而且由於task與wiki，code review都在一個系統中，每個task的說明能夠與產品技術說明直接關聯，每個人都可以看到該task的相關進度
對於產品經理or項目經理來說，phabricator也是非常好的選擇

正在使用Phabricator，我感覺它是：「真tmd的好」

從拋棄jira，將redmine遷移到trac，專心折騰trac兩年，再用上gitlab以後，雖然每個工具定位不同，但是總體感覺沒有一個工具真的是在做「人」做的事情：
1. 溝通，Phabricator上的溝通是主對人，特別是owner這個角色，非常適用於使用快速迭代的團隊。你還在用qq和郵件做報告和推進迭代？
2. 合作，Trac上無法merge request，gitlab直接搬github。硬傷就不說了，問題是merge request並非是admin/master的工作，gitlab需要新開一個fork的行為，而Phabricator的audit是非常直觀的：誰是owner，就都可以對此commit進行審核。
3. 獨立，trac和gitlab都無法對自身以外的repository進行窺探。於是我在Phabricator上將以前所有trac和gitlab的repository導入。一旦決定拋棄他們，切換到自主hosting就好。同時還支持mirror到源。
4. 開放，你有新的皮膚想用？想用fontawesome？開源。自用自改。

實踐就是：馬上部署馬上嘗試馬上切換就可以馬上開始使用Phabricator而其他淪落為bugtracing（原本是什麼就是什麼）。其他工具想不用想。裝個trac加插件話費一個禮拜匹配版本，jira買或者用盜版，gitlab無。

Phabricator的代碼評審工具是Differential，Arcanist只能說是Phabricator提交代碼評審的工具，不使用Arcanist也能使用Differential進行代碼評審，方法是在Differential界面點擊右上角的「Create Diff」創建Diff和Revision。

Arcanist在Unix下的大致使用方法如下：
1、 arc設置
設置編輯器: arc set-config editor "vi"
設置默認Phabricator URI: arc set-config default http://your_phabricator_url/
2、配置.arcconfig
在項目代碼根目錄創建.arcconfig文件，內容例如
{
"project_id" : "your_project_id",
"conduit_uri" : "http://your_phabricator_url/"
}
此文件可提交到代碼庫上。
3、安裝證書
cd your_project_src_root
arc install-certificate
此命令需要輸入token，瀏覽器打開http://your_phabricator_url/conduit/token/，複製內容粘貼即可，注意使用自己的用戶登錄
4、提交Differential（GBK）
默認：arc diff . --encoding GBK
修改已存在的diff: arc diff . --update D1 --encoding GBK
創建新的diff: arc diff . --create --encoding GBK
從文件提取信息創建：arc diff . --encoding GBK --create --message-file ~/arcdiff.txt
註：arc diff可支持一次創建多個目錄的diff，如不指定目錄則為整個庫。

Phabricator的資料庫使用UTF8編碼（參閱User_Guide_UTF-8_and_Character_Encoding.html），使用網頁提交Diff和Revision以及進行代碼評審時沒有問題，Arcanist也支持其它編碼的代碼庫，國內一般使用GBK字符集，提交arc diff時必須顯式指定GBK字符集編碼，否則如源代碼存在非UTF-8編碼字元則會被保存為二進位文件；
提交diff時在命令行及編輯器中禁止輸入非UTF-8編碼字元，如果輸入了GBK中文字元且保存信息後可能會導致Invalid UTF-8 string passed to phutil_utf8v錯誤，此時需要手工刪除項目代碼根目錄下的.svn/arc/create-message文件方能繼續執行；
如需arc diff 支持輸入GBK字元需要修改Arcanist的arcanist.php和ArcanistDiffWorkflow.php代碼文件。

接觸的Gerrit更多一些。

Jenkins作為持續集成工具之前在上家公司版本管理實踐過，現在的公司用的就是phabricator和arcanist作為code review平台。非常好用！

公司正在用這個東西，如果以前用慣git的朋友還是滿習慣這個的

主要Phabricator把很多功能集成在一起了，很方便。

在安裝的時候，發現了這個問題，重試了多次還是過不去，大家知道什麼原因嗎？或者給一下所有的苦表結構，多謝～～

看上面的評論，phabircator做code Review好像很好用的樣子。有空我去試一下。

我準備安裝這個，但是那個官方的腳本安裝的時候有問題……不知道是不是伺服器上本來就有MySQL的原因不

我是來提問的，phabricator的郵件配置為什麼SMTP配置好之後無法工作。求解答！

phabricator 的代碼提交只能用命令行吧，這點兒在我們公司很多人不喜歡