自動化通過 UCM 管理的 Web 應用程序的構建/部署過程

領測軟件測試網 本文來自于 Rational Edge：學習如何利用基于Java的Apache Ant構建工具的相對簡單的實用工具，來自動化一個 WebSphere 平臺上的Web應用程序的UCM驅動的構建/部署過程。

軟件工程師們經常發現Web應用程序的部署非常消耗時間而且容易出錯。通常情況下，工程師們需要制作可部署的Web應用包，然后人工地將其部署到一個應用服務器上。這種井井有條的開發環境常常跟我在IBM China Globalization Laboratory時的工作很相似。我們用一個集成了IBM Rational ClearCase和IBM Rational Clear Quest的統一變更管理（UCM）基礎架構，為我們的產品處理軟件配置，稱作Translation Communication Tool (TCT)。我們將每一個基于 Web 應用軟件的新版本部署到IBM Webspace Application Serve(WAS)上。

雖然UCM有很多好處，比如版本管理和缺陷管理，但我們在Web應用上發現了不足之處。在利用UCM基礎架構進行部署管理時缺少一個單獨統一的機制，我們的集成人員不得不人手工地去除源代碼（像Java和JSP文件）和內容資源（像CSS和圖像文件），然后利用WAS開發工具構建一個可部署的包，最終手工將這個應用軟件部署到Websphere平臺。盡管UCM基礎架構提供了可取消的API使部署可自動化，但是API在基礎水平上是很難被理解。

在這篇文章中，我描述了一個利用基于Java的Apache Ant構建工具的相對簡單的實用工具，使Web應用軟件在WebSphere平臺上的UCM驅動的構建/部署過程自動化的方法。由于這個實用工具，我們現在只需輕輕點擊鼠標，就可以將構建部署到WebSphere平臺，管理自動測試運行，甚至報告失敗，然后追蹤到最新一次穩定的發布。

需求：更頻繁地發布，更自動化地部署

手工部署不僅僅是為那些創造和部署每一個工作版本的團隊成員引入了錯誤并花費了更多的時間，它還降低整個團隊的效率，改變了構建/部署的生命周期。

因為Web應用軟件的手工部署是十分耗費時間的，開發者們完成了批量的發布版本，這樣就需要更少的部署。我們在幾個星期或者更多的時間內累計了一批代碼修復或者新的特性，然后立即將他們部署。在這期間，一些測試人員沒事可做，等待開發人員將這批可使用的代碼變更或者修復處理好。這并不是最有效的利用技術資源。

當團隊正在加強，修復缺陷，不停地測試新代碼時，這對更頻繁發布新版本是十分有利的。更少的變更，更頻繁的發布意味著每個構建的回歸測試所需的時間越少，用戶能更快地得到新特性的好處，部署團隊在他們的工作上可得到更頻繁、粒度更小、更快反饋的好處。

更頻繁地發布的另外的好處是大大縮減測試人員的停工期。我們發現自動化測試我們產品的所有特性是不可行的。取而代之的是，我們僅僅在關鍵“黑盒”組件（利用JUnit）上自動執行測試，在運行整個產品（HttpUnit）的功能測試上就需要更少的時間。無論如何，為了充分測試重要的功能，大多數情況下手工測試是不可避免，而且是QA工程師們在測試服務器上進行的（有些測試還是由“真正的”用戶在產品服務器上執行的）。因此頻率更高更有效的部署意味著測試人員可以在更連續的基礎上進行測試工作。

一個自動化的解決方案

為解決這些頑固的問題，我們的團隊為我們的TCT產品創建了一個自動構建/部署的實用工具，它讓我們能夠在更短的時間，更少的錯誤下更頻繁地發布新構建，從而提高我們整個生產率和工作效率。

在這個實用工具的幫助下，只需輕松地電一下鼠標，我們現在就可以將我們的Web應用軟件部署到我們的IBM WebSphere產品服務器上，也可以部署到我們的的測試服務器上或者其它平臺上。如果一個測試服務器上的自動測試運行返回或者失敗，這個實用軟件就會通過郵件向開發者報告，通知這個應用集成人員在測試服務器上回到最后一個穩定的發布重新運行。

我們甚至可以篩選出我們想部署或者指定這個軟件的哪個組件，我們想回到先前哪個發布，以及哪個部署點。在最簡單的例子中，我們設定默認設置（比如包括所有的組件），利用克隆腳本自動定期地運行這個構建和腳本部署，正如下面所述。

怎樣使工作自動化

通常情況下，我們設置構建/部署腳本在每天晚上自動運行，從而減小網絡在高峰時段的壓力，同時增加了這個團隊的合作效率。尤其對分布在全世界不同地域的團隊非常有用。例如，中國的一個開發團隊在白天完成了編碼工作，當他們離開時，這個變更可在測試服務器上自動構建和部署。相差很多個時區，遠在德國的團隊執行測試并且為第二天的代碼變更和修復出示結果。（與此相反，手工構建和部署使得開發團隊很難在每晚都構建和部署。因此，測試小組經常需要花好幾天來等待代碼變更和確定的結果。）

下面的部分逐步解釋了怎樣使工作自動化，在很多情形中顯示了所包含的代碼

步驟1：初始化環境變量

首先，我們要為Web應用構建/部署的自動化來初始化全局環境變量。例如，我們需要讀取{web.dir}，{src.dir}，{lib.dir}，{bulid.classes}等等，變量來自于屬性文件，并確保這些全局變量在整個自動構建/部署過程中是可以利用的。此外，我們為了一些特殊任務而讀取一些變量，比如{upload.path}和{deploy.server.name}，都是上傳和部署工作需要的。

下面是實現這個的代碼：

步驟2：從ClearCase更新并同步代碼

IBM Rational UCM的特性是，在這個軟件工件的作用下整合了一個項目中的小應用程序，這個軟件工件在這個明晰的、可重復的過程中是可變的。UCM幫助開發者跟蹤這個變化使這個工件來滿足變化的要求，因為IBM Rational ClearCase 控制著這個隨著新版本一起變化的工件。

下面的腳本同步了來自ClearCase整合版本最新代碼和Apache Ant工具中的備份任務。

步驟3：編譯所有Java 類

通常情況下，對于一個Web應用軟件，所有Java源文件應該被編譯并放在的地址{build.class}，它使WEB-INF/classes所缺少的。在這個構建過程中，我們在Sun 的 JDK中用Java命令來編譯所有的Java類。

步驟4：通過郵件告知構建結果

在自動化過程中，自動生成郵件是一個非常好的便于溝通的方法。我們的自動化通過發送郵件向開發者和項目經理告知構建結果，讓他們知道每個構建是成功完成還是失敗了。通過告知這個構建的錯誤，開發者們能夠調查并識別來自于他們編碼的錯誤。

步驟5：產生基線

在我們的產品的版本管理中基線對我們來說是十分重要的。我們發現最好的自動產生基線的方法是利用Apache Ant自動產生和增加這個構建版本的數字。Apache Ant是通過創建和更新一個名為tct_build_info.properties的文件的條目來實現的。

下面是這個屬性文件中域名值的詳細情況：

一個基線的最重要屬性就是其質量。開發者可以產生無數基線，但是為更進一步的開發他們只能用好的基線。“好的”在這里的意思是可以使代碼可以完全編譯，一組測試可以成功運行的基線。

在基本單元測試完成之前，開發者可以為這個構建指定一個晉升水平，當然也有可能被否決。一旦這整套單元測試順利完成，這個構建就可以升級到BUILD，這意味著我們現在擁有一個很好的基線，它可以為更進一步的開發奠定基礎。圖表1闡述了這個產品內部構建過程

通常情況下，我們需要調用ClearTool 命令直接完成類似于校驗、升級、登記、創建基線等等任務。然而，這些命令與自動構建/部署工具之間的結合相當困難。幸運的是，Ant提供了第三方的任務，很容易地將UCM概念整合到基于Ant的自動構建/部署實用工具中去。圖表1闡明了一個內部構建過程，在這個過程中Ant任務（CCCheckout，CCCheckIn，CCCMkbl，都用紅色標記）都有所用處。

圖1：內部構建過程。 Apache Ant提供了第三方的任務，很容易地將UCM概念整合到基于Ant的自動構建/部署實用工具中去。圖表1闡明了一個內部構建過程，在這個過程中Ant任務（CCCheckout，CCCheckIn，CCCMkbl，都用紅色標記）都有所用處

步驟6：為不同的平臺打包

在許多項目中，有不同的部署平臺，比如一個測試站點相對于一個產品站點，針對不同的站點在Web應用的屬性文件中需要特定的部署變量。例如，當部署一個產品站點，這個構建也許需要所有的應用組件。然而當部署一個測試站點時，你不必包含郵件通知組件，因為你不想在測試站點測試期間的用戶被偶遇的郵件打擾。另一個可能是，產品站點可能運行的是Linux系統，而測試站點可能運行的是例如AIX系統。由于類似的原因，發布工程師們通常需要創建不同的部署場景。

下面的代碼運行了Ant基于不同的部署平臺的三個不同的任務。每個任務采用一個平臺――具有特定屬性（看圖2），然后產生腳本構建與其平臺相一致的可部署的包。

以上提供的腳本產生了兩個Web模塊，包括TCT2.2.war和soap.war，利用了一個特殊的命名規則將它們和一個構建版本的屬性文件整合到一個可部署.ear包中去: ${tct.ear.name.prefix}.${today}.${build.version}.ear.

圖2：TCT夜晚構建過程

步驟7：上傳包到WebSphere Application Server

下面是一個Ant任務，在WebSphere Application Server(我們的產品Web服務器)上上傳一個a.ear可部署包到{installableAPPs}地址：

上面的腳本通過一個自動化部署管理命令，將這個步驟6中產生的這個可部署包上載到WebSphere Application Server中一個臨時地址來應用。這個命令將在下一步來解釋。

步驟8：WAS上的遠程登陸/部署和重新啟動

下面是Ant任務，遠程登陸到WAS服務器并運行部署腳本“appinst2.jacl”：

下面是部署腳本，它可以通過WebSphere Application Server平臺提供的wsadmin.sh命令轉化并運行：

步驟9：構建服務器的結構

為更進一步提高我們構建過程的效率，我們已經配置了一個服務器專門運行我們TCT產品的夜晚構建。我們基于平臺變量創建了一個文件夾結構和構建號碼來維持先前的所有構建。當一個夜晚構建失敗時，我們能夠很容易地跟蹤到先前任何一個穩定的發布，開發者們可以重新創建一個新的可使用的版本進行測試。圖3闡明了我們構建服務器的結構。

圖3：TCT構建服務器的結構

關于圖3，請注意下面幾點：

• 構建由腳本產生，可自動考慮平臺的相關性（注意圖3中的“Configure App properities”）。
• 在任何一個平臺環境，構建通過內部構建版本號進行組織。例如，在一個我們稱作Common Development and Testing(CDT)的平臺，發布由構建號如TCT2.0.1000，TCT2.0.1001，等來組織。
• 如果一個構建失敗，最近的一個穩定構建將在應用集成人員的要求下被自動上載并部署到WebSphere Application Server。例如，在一個我們稱作Local Testing Server的服務器上，如果構建TCT2.0.1001失敗了，應用集成人員會篩選最近一個穩定的構建，上載并部署。

結論

我們的開發團隊通過在我們強大的CUM環境中使用自動構建實用工具，獲得幾個重要的利益：

• 提高效率。我們能夠每天自動構建和部署我們Web 應用軟件。當構建失敗時，開發者們可以自動收到報告錯誤的郵件，先前穩定的版本可以自動重新獲得。
• 可跟蹤性。我們可以自動記錄帶有版本和發布的可部署包。只需發布工程師的一個簡單的請求，每有個新的發布都會自動轉化并毫無差錯地重新運行。
• 靈活性。現在對于團隊來說采用不同的發布環境容易多了，因為我們的構建/部署實用工具可以在不同的平臺環境下自動產生不同的與之相匹配的可部署包，并將他們自動部署。

我們的自動化實用工具對于一個Web應用軟件中的構建和部署過程提出了兩個主要的問題。一個是在巨大的類似UCM這樣的基礎架構中手工操作時，產生的耗時和容易出錯的問題。這個問題由基于Ant的腳本解決了。另一個問題是由Web應用軟件本身的構建和部署的復雜性導致的平臺相關性問題。這個問題由我們強大的高敏感度平臺腳本解決了。我認為這些平臺相關類型的腳本對于其它夜晚構建的要求同樣有幫助，包括Ant+CVS，Ant+VSS等等。

我認為無論是新手還是中等水平的實踐者都會從這里的技術描述獲利。通過使用這里提供的代碼和腳本，運行這個構建/部署過程，你只需要將你Web應用軟件中有關平臺的部分整合到不同的配置地址就可以了，如圖3所示。然后你就可以實現這三大利益：高效性、可追蹤性和靈活性。

延伸閱讀

文章來源于領測軟件測試網 http://www.kjueaiud.com/