
222
| 第九章
你學過的復審規則都適合這一種復審風格。你不能因為編寫程式的開發者不在你的辦公
室(或建築物或國家)工作而不試著同理他。
Gerrit:主觀的復審工具
Gerrit(
https://www.gerritcodereview.com/
)最初是在 Google 內部製作的,它提
供主觀的 web 程式碼復審與存放區管理讓 Git 使用。正如同 Gerrit 網站上的討
論,當開發者進行修改時,它會被送到這個待決(pending)變動的存放區,讓
其他開發者可以復審、討論與批准那項變動。Gerrit 也會捕捉每一個變動的筆
記與評論。當這項變動被足夠的復審者批准之後,它就可以成為基礎程式的官
方部分。雖然 GitHub 與 GitLab 等 Git 平台都可以在一個 pull 請求裡面做多次
提交,但 Gerrit 不行:一個程式碼變動就是一次提交,無論它是加入功能還是
修正 bug,而且討論會圍繞著它展開。
將組建自動化
下一章會探討更多關於組建自動化的內容,重點是從管道進行部署與釋出,但它們也是
CI 的關鍵程序。雖然 Maven 與 Gradle 等組建工具都可讓每位開發者在本地機器上執行
組建程序,但我們仍然需要一個中心來組建整合後的程式碼,我們通常會使用組建伺服
器(例如 Jenkins 或 TeamCity)或組建服務(例如 CircleCI 或 Travis CI)來做這件事。
Jenkins
在
https://github.com/danielbryantuk/oreilly-docker ...