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