Someday, all software will be built this way.
原文鏈接：http://alblue.bandlem.com/2011/02/someday.html
(筆者注：文章主要介紹Git，Gerrit，Jenkins爲代表的版本控制，代碼審覈，持續集成工具在現代軟件開發中的使用，筆者認爲這些都是當下最時髦，最先進的開發工具和工程思想，特做簡單翻譯與大家共享。)
先從代碼審覈說起，代碼審覈系統總的來說分爲兩類，各有優缺點：
- 提交前的審覈，即把所做的改動附到審覈系統。好處是避免了因爲不準確或者不存在的版本號碼而搞亂版本控制系統；缺點是提交的審覈意見可能和提交的代碼改動不吻合。
- 提交後的審覈，即不管三七二十一先把代碼提交到版本控制系統。好處是所有的改動和審覈意見都保存到了版本系統中；缺點是錯誤的改動可能會搞亂版本控制系統。
解決方案是使用branch（筆者暫且稱之爲分支，以區分稱爲主幹的HEAD）。當改動被保存到分支時，就不會影響到其他在主幹上工作的開發人員。審覈人員可以獨立地在這個分支上進行代碼審覈，提出建議，修改，完成審覈後最終把改動保存到主幹。當然，如果需要做兩個同時發生的改動，則需要兩個分支。
顯然，分支就會帶來合併。以使用Git爲例，開發人員可以在本地的分支上做代碼改動，push這個分支到中央倉庫，請審覈人員（一般即同組的其他開發人員）進行代碼審覈，最後把審覈過的改動合併到master（HEAD，trunk，即主幹）中。因爲Git是分佈式版本控制系統，最後的合併將包含所有的歷史改動（包含審覈人員的意見和簽名），這樣當有人說“張三批准了01b3cd這個改動”時，開發人員可以準確地看到這個改動具體是什麼。
下面來說說Gerrit。
Gerrit是和Git有良好互動的代碼審覈系統。Gerrit一般處在開發人員的本地Git倉庫和Git中央倉庫之間。簡單來說，開發人員將改動push給Gerrit，Gerrit提供一個專業的審覈平臺，審覈人員可以對每個改動過的文件，甚至對每一行改動進行評論。Gerrit同時保存審覈投票，包括+1和-1兩種，默認情況下，每個改動需要得到+2的投票纔算審覈合格。
下面說說Jenkins（即以前的Hudson）。
作爲一項近年來十分流行的持續集成工具，Jenkins能夠從版本控制系統中取出最新的代碼，編譯，運行測試，並將結果email給相關人員。Jenkins支持隨心所欲的觸發。開發人員可以設定每天晚上服務器空閒的時候觸發Jenkins，或者設定當版本控制系統檢測到改動時觸發。通常情況下，每次只觸發一個分支上（或者主幹上）的編譯運行。Gerrit有一個觸發器可以在每產生一條新的審覈意見時觸發Jenkins，它甚至能告訴Jenkins取出改動的那個或者那些文件，編譯，然後自動運行所有的測試。當Jenkins完成編譯運行無誤時，Gerrit會自動針對這些改動發表+1（Verified）意見，相反地，如果Jenkins上編譯運行有錯，則發表-1意見。通過配置，所有這些可以在審覈人員還沒有開始審覈時就全部完成。另外，Git還有一個插件（Git Plugin）可以用來把成功的改動push到遠程倉庫中，這樣所有人都知道這個改動已經在Jenkins上成功通過了編譯和測試。
這樣，一旦一個改動被push到Gerrit，Jenkins自動進行集成（編譯，測試，標記+1），審覈人員進行審覈，填寫評論（可以不填），增加+1標記（可以設置爲不需要增加），這個改動就視爲一個正確改動了。因爲Gerrit參與整個流程（Jenkins成功後會在Gerrit標記+1，失敗後會標記-1），因此Gerrit能夠代表開發人員將審覈合格的改動push到主幹（遠程服務器，比如Github或者bitbucket）中去。
一旦開發人員開始使用Git，就會充分體會到分佈式版本控制系統的好處。一旦開始使用Gerrit，就不存在未經審覈的改動。一旦開始使用Jenkins，開發人員就不需要手動運行編譯，測試工作。這就是當下最紅的軟件開發工具和思想。