構建自動化駛向何方?(2)

　　輕量級且運行很快的單元測試可以被迅速的執行完，并且在測試失敗時能夠給出很快的反饋。而另一方面，如果緩慢運行的集成測試與單元測試混在一起，那么單元測試將要花上更多的時間來執行，結果開發人員也要等更久才會得到關于單元測試失敗的消息。解決之道就是為單元測試和集成/性能測試創建單獨的構建計劃。使用這種方式后，如果單元測試構建計劃失敗了，由于其執行速度很快，開發人員不再需要等待很長時間才被通知到構建失敗。如果單元測試成功后，集成測試和性能測試計劃才會開始。

　　另外，還有一個補充方法——可以使用分布式構建。例如，如果你的web功能測試由于要在幾個不同的瀏覽器上運行并因此消耗很長時間，那么可以為每一個瀏覽器設立一個構建作業，以讓它們(可能在不同的機器上)并行運行。

　　另一個問題來自過于緩慢和效率低下的測試用例。有許多方法可以用來監測這些緩慢的測試。提高測試上的運行時間意味著有些測試會由于所需時間太長而無法運行。這也許是因為它們被設計的很糟糕，也許是因為性能問題(需要進步一深究)，抑或是集成測試偽裝成了單元測試。

　　密切關注代碼質量

　　持續集成服務器不應當僅僅是一個自動構建的機器。它應當成為你團隊中溝通的中樞，尤其在代碼質量上。時刻關注編碼規范和一些度量值如代碼覆蓋率以及代碼復雜度，它們可以讓應用程序更加可靠且更易維護。

　　有很多優秀的工具可以幫助維護應用程序中良好規范的代碼。靜態分析工具如Checkstyle，PMD和FindBugs，它們根據代碼標準、最佳實踐或者潛在的bug來對代碼進行分析。你所有使用的工具如何配置要依賴于你想要達到的目標。例如，Checkstyle更多關注于編碼規范和最佳實踐，而 Findbugs則更傾向于找出錯誤的，破碎的或者危險的代碼。所有的這些工具可以很輕松地集成到自動化構建過程中，并且可以和Ant、Maven一起很好地工作。

　　覆蓋測試率是代碼質量的另一個方面。它用來衡量測試執行時所訪問的代碼行數。Java開發人員中對覆蓋測試率統計的相對值仍然有著分歧。事實上，雖然它可以告訴你應用程序中的哪些行被執行，但是沒法知道那些測試是寫得很徹底、寫得很好，抑或僅僅是簡單的走馬觀花?？偠灾?，測試覆蓋率不能保證你的測試質量很高——只有人工進行代碼檢查時才能確保如此。然而覆蓋測試率的度量值可以很好地展示出哪些代碼沒有被測試過。在Java世界里，用得最多的代碼覆蓋率測試工具當屬Clover和Cobertura，前者是一個非常強大的商業代碼覆蓋率測試工具，而后者是一個更加輕量級的開源工具。它們都可以很容易地集成到基于Ant和Maven的構建腳本中。

　　編碼規范也可以作為非常有效的培訓支持和指導活動，尤其對于那些經驗不足的開發人員。CI工具可以提供這些數據如何隨著時間的推移而變化的高層次圖片，還可以關注開發人員在應用他們學到的技巧時做得有多好。例如，如果一個類只有很低的代碼覆蓋率，甚至沒有，就意味著某個新的開發人員在消化吸收小組培訓的測試驅動開發和測試實踐上出現了問題。這種方法還可以通過代碼審查和定期的代碼質量會議(討論任何新問題或者動向的會議)完成。

　　一旦構建結束——自動化部署過程

　　構建應用程序只是開發生命周期中的一部分。一旦代碼編譯測試后，需要進行其他的活動，例如部署到階段性(staging)環境、冒煙測試、功能測試和性能測試、準備發布說明和提醒QA人員最新的發布。

　　將最新的構建結果自動部署到集成服務器上是一件相對簡單的事情。而將其部署到階段性環境或者生產環境下，則需要涉及一些與常規構建作業不一樣的工作。一般而言你需要一個更加嚴格，更加正規且有更多可跟蹤性和問責的過程。它通常涉及到的任務如下：

　　* 為階段發布標記源代碼

　　* 編譯測試應用程序

　　* 發布構建產品

　　* 將應用程序部署到階段性環境中

　　* 運行數據庫更新腳本或者其他特定環境腳本

　　* 運行冒煙，功能和性能測試

　　* 準備并發布產品說明

　　* 提醒關于最新階段發布的相關利益人

　　這通常是一個手工任務，但是其中的大部分工作沒有理由不能自動化。事實上，開發生命周期中的自動化包裝，部署和發布具有很穩固的商業意義。一方面自動化能夠得到更加可靠的構建：計算機不會忘記部署過程中的某一步，也不會在發生測試失敗后繼續進行。它還能夠節約開發人員的時間：階段性發布由之前幾小時的 shell腳本編程變為了只要點擊一下按鈕。它比以前的速度要更快，并且可以在沒有人的情況下完成工作(例如，通宵或者午休時間)。

　　像Maven 2這樣的工具也能夠幫助自動化一些步驟。Maven Release插件使得Maven的用戶能夠自動化處理一些如“更新版本號”，“Subversion中新增標簽”，以及“向Maven存儲庫中發布構建產品”的工作。它可以用來管理階段構建，并決定在不同的環境部署不同的發布產品。盡管如此，一旦產品構建結束并且可以部署到階段性環境者生產環境時，這個過程就會變得更復雜。

　　千真萬確，現實世界中的部署步驟數目經常要比簡單的用一個WAR文件多。根據應用程序架構和產品平臺，你可能需要在階段性環境者生產環境下的數據庫中運行SQL更新腳本、用一個專用的工具部署web服務、運行自動化的冒煙測試或者做一定量服務端的工作。

　　CI可以幫助簡化比這些還要復雜的步驟。例如通過分布式構建，你可以設立階段性環境或生產環境上的構建代理，并在該機器上直接運行相應的任務。幾乎所有的 現代CI工具都支持相當好的安全模型，目的是為了將應用和產品環境限制給一些特定的人，以及跟蹤誰在什么時間運行了什么構建。

　　這是CI的一個相對較新的應用，不同的工具在處理應用程序部署時使用的方法也不一樣。有一些，如Hudson，允許在構建作業中定義多個步驟，只有當前一 個步驟成功后，才能執行后續步驟。其他的像Cruise和Anthill Pro，都嘗試將部署生命周期中的如階段和生產環境直接集成到構建工具中，盡管有時候這樣會帶來額外的復雜度開銷。

　　還有更多低層次的操作可以和CI服務器聯合起來使用。一個選擇是使用諸如Ant或者Maven的構建工具。Ant對于這種類型的腳本特別靈活。另一個流行的選擇是古老的Makefile，或者Unix上的shell腳本。它們的缺點是操作系統相關的，并且對于那些不熟悉shell腳本精髓的Java 開發人員來說很難掌握。想要與Java更加友好，可以選擇動態語言諸如Groovy或者Gant(一個使用Groovy而不是XML來制作Ant腳本的工具)。 Groovy在提供所有輕量級的動態腳本語言中所有的優點的同時，也保留了對Java開發人員的熟悉程度和可讀性。

原文轉自：http://www.kjueaiud.com