《配置管理最佳實踐》——2.5 構建工具評估和選擇

本節書摘來自非同步社群《配置管理最佳實踐》一書中的第2章，第2.5節，作者： 【美】Bob Aiello , Leslie Sachs著，更多章節內容可以訪問雲棲社群“非同步社群”公眾號檢視

2.5 構建工具評估和選擇

目前有很多好的構建工具，也有很多相關的最佳實踐教程。這些教程可以指導你建立一個可靠、可擴充套件的構建流程。這裡將會討論一些工具和最佳實踐，你可以有選擇性地實施其中一些來支援公司的開發工作。目前軟體開發中主要有幾類比較流行的構建工具。不久以前，有段時間構建自動化僅僅意味著使用 Make（也許還有一些 shell 指令碼）自動執行構建過程的每一個步驟。這種方法可以很好地支援 C 和 C++ 的構建。但是在實現的時候，要注意底層不同平臺帶來的差異性。我在 HP-UX, Solaris, AIX 和 Linux 上都用過 Make。 Make 是1977年由斯圖爾特·費爾德曼在貝爾實驗室創造的。 GNU Make 相對於 Make進步了一些，解決了一些跨平臺的構建問題。值得注意的是， Make不僅僅可以用在 C 和 C++的專案上，某些情況下也可以用來構建 Java 的專案。

2.5.1 Apache Ant 進入構建舞臺
作為Apache Tomcat 專案的一部分，Ant 最初是由詹姆斯·鄧肯·戴維森（James Duncan Davidson）創造的。一開始Ant 是和 Apache Tomcat 被捆綁在一起使用。到2000年7月的時候， Ant 1.1 才作為一個單獨產品被髮布。Ant 與Make截然不同，它是基於 Java 實現的，而 Make 僅僅是通過一些shell 指令碼來構建的。

2.5.2 Maven
Maven 一開始是作為Jakarta Alexandria 專案的一部分在2001開發的，在後來卻作為一個單獨產品被髮布了。 Maven 目標是成為集中整個專案資訊源的標準化的構建框架，並自誇：“需要寫很多行Ant XML 程式碼的活，Maven 可以輕鬆搞定。”Maven 是基於約定優於配置的理念，也就是說 Maven 希望使用者遵守它定義好的宣告和約定來使用Maven。Maven 通過生成框架的機制可幫助你初始化一個符合約定的專案。Maven 生成的框架程式碼可幫助你使用不同的Java 框架。Maven 的生命週期是非常重要的概念，理解好每一個生命週期，有助於使用 Maven的更多功能。
2.5.3 Maven 與 Ant
Ant 需要大量的 XML 程式碼來描述到底要做什麼。從這個意義上說，Ant 比Maven更注重過程。 而Maven 在專案描述上採取了截然不同的做法。Maven規定應用程式應一直遵守一個特定的結構。這也就是前面所說的 Maven 倡導的約定優於配置的概念。 Maven愛好者認為開發人員必須以 Maven 的標準來組織應用程式結構。這樣Maven 就知道資源都儲存在哪裡，哪些是需要構建的，剩下的 Maven 就可以自己完成了。Maven 1.1使用的是 Jelly 指令碼，而Maven 2 使用的是純 Java 的 XML。Maven 有一個定義好的生命週期，理解了Maven的生命週期就可以更大地提高構建效率。在實踐中，許多構建工程師使用Ant 外掛來擴充 Maven 的功能。 Maven 預先為你定義了專案框架，儘管對於複雜的構建，這個框架可能不是特別順手。當在兩個都備受推崇的工具中選擇時，開發者一般都有各自的偏好，有些甚至是固執己見。在曾經工作過的幾個公司裡，我用 Maven 1.0.2和 Maven 2.0構建過規模相當大的產品，當然也用過Ant 6 和Ant 7。我認為每個備受推崇的工具都有自己的優點和固有缺點。

2.5.4 使用 Ant 生成複雜構建
Ant 被用於生成複雜構建時，很快就會陷於一堆笨重且雜亂的XML中。 Ant 指令碼要好好地組織結構，儘量減少每一步之間的依賴，以便其都可以單獨地執行。例如，呼叫原始碼管理工具的程式碼內嵌到 Ant 構建專案的目標（target）當中。 這就導致每次呼叫Ant 編譯Java類的時候都會呼叫原始碼管理工具。其實這是沒必要的，因為有可能我在本地做一個構建，而原始碼早已經在本地工作空間中，這時根本就不需要重新獲取一遍程式碼。此外當團隊從一個原始碼管理工具轉到另一個時，就必須檢查整個專案的 Ant XML檔案，修改每一個涉及原始碼管理操作的部分。實踐中應該避免這樣的Ant 組織結構，儘量使每一步都相對獨立。還有一點要談的是當原始碼管理系統關機維護或者備份的時候，構建團隊就不能構建專案的情況。好的構建工程指令碼應該採取結構化的方法，建立開發沙箱後，可以單獨地進行編譯。構建不應該依賴於原始碼管理工具是否正常執行。

2.5.5 持續整合
持續整合是現在十分流行的最佳實踐之一，它要求在開發人員每次提交變更到程式碼庫後，都立刻進行構建和部署程式碼。雖然一開始持續整合流行於敏捷開發領域，但是現在在很多非敏捷開發環境下，持續整合也是一個廣受推崇的最佳實踐。持續整合系統一直監控原始碼管理系統中的變化，一旦有變更就會立刻觸發構建。構建的結果會發布在顯示皮膚（dashboard） 上，包括導致最近系統故障的變更、構建失敗的變更等。每個持續整合系統都是不一樣的，在公司中使用之前，應該根據其功能來評估是否適用。

2.5.6 持續整合系統
目前有很多非常受歡迎的持續整合系統可供選擇。持續整合是配置管理中最令人激動的領域，有很多很強大的開源解決方案，當然也包含很多擴充套件功能的商業產品。在有新程式碼提交到程式碼庫時，先進的持續整合系統都支援自動發起構建的功能。另外，也可以安排一個特定的時間，例如每天晚上自動觸發一個構建。持續整合系統通常都可以識別出最新的變更，尤其是最後造成構建失敗的變更。大多數持續整合系統都使用 XML檔案進行配置。有些系統已經具有強大的圖形化介面，這使管理變得更容易。

2.5.7 整合開發環境
整合開發環境（IDE）可以讓開發人員以迭代的方式快速開發應用程式，幫助他們提高工作效率和產品質量。整合開發環境通常會安裝一些外掛，就可以在裡邊使用編譯器(例如C++ 或 Java的編譯器)來構建專案。構建工程師面臨的挑戰之一就是開發人員只知道在整合開發環境中構建產品，這就會導致其很難寫出一個可以在命令列下執行的構建指令碼。一些整合開發環境可以生成在命令列下執行的指令碼。在整合開發環境中構建出的應用程式是絕對不可以部署到生產環境（或者QA環境）中的。因為通過整合開發環境生成構建的方式在本質上是不可重複的。最大的問題就是開發人員常常不瞭解那些由整合開發環境隱藏了的構建過程。

2.5.8 靜態程式碼分析
構建工程通常被認為是進行靜態程式碼分析的最好時間點。因為構建工程師控制所有原始碼的構建和釋出，所以可以插入一些打樁程式碼（instrument code）生成一個用來進行靜態程式碼分析的構建。自霍爾斯特德複雜性度量（Halstead complexity metrics）成立之初，我就做過靜態程式碼分析的工作。使用靜態程式碼分析工具可找出可能存在的安全漏洞，並且在程式碼釋出之前修復。構建工程師往往是唯一的可以把所有程式碼都放到一起構建出釋出版本的人。構建工程師還可以通過指令碼和適當的修改構建出整個系統，這對於靜態程式碼分析來說都是必要的。顯然，用來做靜態程式碼分析的構建通常包含打樁程式碼，所以這樣的版本通常也不能部署到生產系統中去。

2.5.9 構建框架
我曾經使用過很多不錯的構建框架，它們都可以提供廣受好評的結構化方法來開發一個完整的構建解決方案。大多數產品都可以讓使用者制訂構建計劃，分配構建代理（build agent），並把所有的結果反饋到統一的構建顯示皮膚上。這些產品也許是整個應用程式生命週期（ALM）解決方案的一部分，也許是擴充套件了某些特定功能的擴充套件外掛。這個時候就需要花費一段時間評估可用的構建解決方案，然後再為公司選擇合適的構建工具。

2.5.10 構建工具的選擇
選擇合適的工具是一件非常重要的事情，通常包含估計實際需求、進行工具評估和協調團隊達成共識。在實踐中，許多專業技術人員發現很難選擇一個適合自己的工具。這首先就要找到支援專案中所採用技術的工具。下面是一些例子：

GNU make 支援C/C++

Ant, Maven 或 GNU make 支援Java

MS Build 或 GNU make 支援 .NET (e.g. C#)

2.5.11 對比優缺點達成一致
在選擇工具的時候，應該儘可能地讓所有利益相關者都加入到這個過程中。在一些公司當中，是開發部門做決定說我要選擇哪個工具；而另外一些公司，則是以更民主的方式來選擇。很久以前，一夜之間大家都開始談敏捷開發。心理學家發現自我管理的團隊更有效，尤其是獲得高生產效率和高產品質量方面。自我管理團隊，顧名思義，有權力來評估和選擇自己團隊使用的工具。達成共識是任何一個成功的自我管理團隊的核心競爭力之一。每種方法都有優點和缺點。我的建議是哪種方法適合自己公司的文化，就以哪種方法去選擇工具。總體而言，在軟體開發工作中，調研工具，對比工具優缺點，分享評估結果，最後達成一致往往是選擇工具或者流程最好的方式。