專注在該費心的工作上，用 CI 來提昇程式品質

在開發的過程中，很常會遇到新上的 patch 不小心弄壞了已經存在的功能。處理這種 regression bug，尤其是在已經有大量 patch 加入了程式碼之後，要找出當初弄壞這個功能的 patch 更是難上加難。現在已經有一些工具能夠幫助你用 bisect 以二分法來找出造成問題的 patch，但還是要花費不少時間，若是能夠在第一時間預防，在 patch 加入後就進行測試，就能夠大輻降低開發時會遇上的問題。為了解決這種問題，自動化測試就能夠在這方面佔有很大的優勢，快速且全面的自動化測試能讓開發者和專案管理者盡早得知目前的專案品質，及早做出反應。

然而，有沒有辦法可以更有效率的提昇整個開發品質呢？大部分有經驗的開發者都會選擇使用 CI server (Continuous Integration Server) 做為開發的輔助工具。CI server 可以負起編譯 (compile)、部署 (deploy)、測試 (test)、整理結果 (report)，的工作。藉由 CI server 定期的編譯程式碼，並進行測試，可以讓開發者每隔一段時間就能取得目前的專案狀態。目前市面上開源的 CI server 中，將常被使用的有老牌子的 Hudson CI、以及它再版的 Jenkins CI、新興起的 Go、支援小型專案做線上測試的 Travis CI、…等。其中筆者最推薦使用 Jenkins CI 來進行自動化集成及測試，它的設定簡單，支援的外掛模組也很多，不少人會推薦使用它，目前 Mozilla 內的小型專案也有使用。

Mozilla 在 CI 的部分有特別花了一番工夫，我們自己設計了一套 ，比較特別的地方是它不只是完成 CI 的自動編譯的工作，它將工作區分成幾個比較細的部分，包含了 Try Server、In-bound Server 和 mozilla-central 三個區塊。 Try Server 提供開發者在實際送出 patch 之前就能夠有進行測試的地方，它可以讓開發者不需要等到實際送出 patch 之後才能完整執行過所有的測試； In-bound Server 則是將開發者已經完成並通過 review 的 patch 在獨立的空間整合並進行測試，這邊的整合結果並不會影響開發中的 trunk，但是卻能夠先看到整合過後的結果。在 patch 整合進 trunk 後，mozilla-central 還是會定期進行整合測試，以確保不會有相容性的問題。

你有用過 CI 嗎？不妨找個容易操作的 CI，提昇一下開發效率吧。