淺談每日建置、BVTs之目的

我任職的公司，今年年初時，指派我用 CruiseControl.rb 規劃了一套每日建置系統。到目前為止，已經運作了超過半年的時間。也確實解決了許多潛在的軟體開發風險，例如 簡化專案交接風險。

不過隨著人員更迭，我時常要對新進員工灌輸每日建置系統的用處。本文就是我每次都會對新進人員說一遍的內容。

每日建置系統並不是什麼特殊的工具。就概念上來說，它只是把我們的專案建置動作，定期自動執行，並把結果記錄下來而已。它並不具備讓我們一建好每日建置系統後，就會自動解決所有問題的特殊魔力。

BVTs (Build Verification Tests) 是自動建置的一部分，這項測試會在軟體自動建置的時候執行。BVTs 的目的是要找出因為修改或加入新的程式碼所造成的副作用和錯誤。 Ivar Jacobson，《軟體工程與 Microsoft VSTS》(中譯版)

BVTs 包含了單元測試、功能測試、需求測試等項目。單元測試是其最基本的內容。在我眼中，它是每日建置系統的血肉。缺少自動化測試項目，則每日建置系統所記錄的內容，不具有參考價值。

每日建置系統不等於持續整合，但卻是達到持續整合目的的必要工具。那麼我們為什麼要建立每日建置與持續整合系統呢？因為下列理由:

• 為了定期自動執行，它強迫我們用文件記錄專案的建置動作。此處所說的文件，絕不是那種死板板寫在文書檔中的文字，而是 Makefile, build.xml, shell script 這種可以交付電腦執行的文件。
• 在測試驅動開發的的觀點中，測試案例兼有進度追蹤的功能。我們可以藉由測試結果來追蹤專案項目的完成度。綠燈表示完成，紅燈表示未完成。
• 它將專案的進度與錯誤報告透明化、公開化。我們所用的每日建置系統 CruiseControl 提供了 web 介面，專案中的每個人，都可以看到每一次的建置記錄內容。
• 當專案內容被切割成不同部份，交由不同人員負責時。每日建置系統提供了一個整合建置與測試的場所。
• 它讓我們及早發現問題。承前一項所說，我們每個人都可以檢視建置記錄。當專案建置錯誤時，我們每個人都可以發現問題，而不會讓錯誤持續存在。

就技術面來說，建立持續整合系統並不會耗費多少成本。但是就實務面來說，卻必須克服許多的問題。這些問題，都跟「人」有關。這些問題所涉及的，通常是觀念，而不是技術。

一般來說，初期的困難是推動測試先行的觀念，後期的困難則是專案進度的壓力。這兩點其實是同一件事，那就是「趕進度，沒時間」。然而，在眾多軟體工程書籍提到的實務經驗中，揭示一個違反直覺的結果。當我們為了節省開發工作而忽略掉測試案例與自動建置工作時，其結果反而是更多的開發時間與專案交付時程的延期。

也請參考《軟體開發之建置風險的故事》了解更多關於持續整合的益處。