級別: 中級

Anthony Bernal (abernal@us.ibm.com), 高級 IT 咨詢專家, IBM Software Services for Lotus
Varad Ramamoorthy (varad@us.ibm.com), IT 咨詢專家, IBM Software Services for Lotus
Yixing Gong (yixingg@us.ibm.com), 高級 IT 專家, IBM Global Business Services
John Barron (jwbarron@us.ibm.com), 高級 IT 專家, IBM Global Business Services
Julia Weatherby (jw@us.ibm.com), IT 專家, IBM Software Services for WebSphere

2006 年 8 月 14 日

設計流程，并建立用于開發(fā)、構建和部署門戶的環(huán)境。了解如何控制源代碼和用于構建組件、管理持續(xù)集成和部署到測試環(huán)境的各種方法，以及如何部署生產發(fā)布程序包。了解相關最佳實踐、可使用的工具和策略，以創(chuàng)建您自己的流程。

引言

在創(chuàng)建新的門戶系列的這一部分中，您將了解如何創(chuàng)建自己的流程，以便在 WebSphere Portal 環(huán)境中構建和部署代碼組件?？梢詫⒉煌募夹g和產品集成到您能夠管理的內聚系統(tǒng)中。

• 可以將整個任務視為一系列流程：
• 控制源代碼和構建組件
• 持續(xù)集成和部署到測試環(huán)境
• 定義和部署生產發(fā)布程序包

本文提供了一些最佳實踐和通用信息，用于幫助您創(chuàng)建自己的流程。文中概略介紹了編譯（或構建）代碼、在門戶框架內部署自定義門戶應用程序的基本流程和相關基礎設施。

構建和部署流程為何重要？

那么，此討論為什么重要呢？如果您進行過任何類型的 IT 或軟件項目，就可能知道這個問題的答案；不過，為了清楚起見，我們將在此處說明其原因。

構建和部署流程可幫助確保以下事項：

• 代碼將由所有開發(fā)人員進行簽入、存儲和版本控制，因此不會丟失任何重要的智力資產。
• 相關項不能在未經(jīng)過可靠性流程的情況下進入生產環(huán)境。
• 如果出現(xiàn)錯誤或者對系統(tǒng)進行了錯誤的更新或配置更改，系統(tǒng)上的代碼庫可以重新生成。

雖然在本文中您還會了解到某項流程之所以重要的其他原因，但主要值得注意的方面如下：

• 門戶及其相關基礎設施
• 門戶應用程序或自定義代碼

這些因素是相互交錯的；不過每個因素都會具有其獨特的設計特點和挑戰(zhàn)。理想的結果是，這些相關項能彼此協(xié)作，從而提供工作正常的門戶來供客戶使用。

此流程如何影響我的項目？

最開始的時候，您可能看不到配備構建和部署流程的任何好處。事實上，可能看起來要進行大量的工作，要實現(xiàn)更多的結構和規(guī)則，但其回報卻甚微。不要被暫時現(xiàn)象所迷惑，因為該流程的價值將可能很快就會體現(xiàn)出來。

例如，項目生命周期中的一個重要時期就是正式投入使用前的那段時間?；A設施已經(jīng)就位，已將部分代碼部署到環(huán)境中，且正在進行測試。在大多數(shù)環(huán)境中，會進行多種類型的測試，如：

• 質量保證測試
• 用戶接受度測試
• 負載或性能測試

其中的每種測試類型都可能導致開發(fā)團隊根據(jù)反饋再進行一次開發(fā)循環(huán)，從而可能創(chuàng)建軟件的新版本或錯誤修復程序。

而這正是很多項目出現(xiàn)錯誤的地方。隨著不斷創(chuàng)建各個組件的不同版本并需要對其進行部署和測試，能夠在不同環(huán)境中快速構建、部署和測試就變得至關重要了。同樣重要的是，需要知道每個環(huán)境中部署了每個組件的哪些版本以及測試的結果如何。

沒有一個流程適合所有的情況。不同的組織需要采取不同的方法。團隊組織結構、行政結構、代碼存儲庫以及構建工具的選擇都會影響您的流程的工作方式。您可以選擇本文中提出的觀點來設計自己的流程。

門戶的流程是否與其他項目的流程不同？

就本質而言，門戶與其他 J2EE 項目并沒有什么不同；不過，門戶框架的確有一些限制和挑戰(zhàn)。您需要確定如何設置項目以在 IDE 內最好地工作和支持一致的構建，還要確定如何將不同的組件部署到不同的環(huán)境中。

構建 Java 組件與大部分項目基本相同，特別是 J2EE 或服務器端組件更是如此。主要區(qū)別是會使用不同的庫和 API，且需要對項目進行恰當?shù)脑O置，以充分利用您的 IDE。

流 程的部署部分可以使用與部署非門戶 Web 應用程序時不同的工具或方法。門戶和 WebSphere Portal 環(huán)境要求進行額外的配置工作，而不僅是安裝 Portlet 或組件。您需要考慮門戶布局和訪問控制問題；可以使用特定于 Websphere Portal 的 xmlaccess 命令進行配置、版本控制和部署工作。本文稍后將介紹有關這些注意事項的更多信息，另外還會提供一些可應用到您的項目構建和部署流程的技巧。

回頁首

建立開發(fā)流程

處 理開發(fā)、構建和部署問題時，需要考慮的問題的確全部都與流程相關。開發(fā)人員并不太喜歡存在大量流程，因為他們感覺到流程對其形成束縛，無法盡可能快速方便 地完成相應的工作。實際上，我們的目標是相同的；即，我們的目標是建立一個簡單的、不會帶來干擾的流程。這個方法是成功的關鍵，該流程應始終從開發(fā)人員角 度考慮問題。堆砌一些技術步驟或復雜步驟，并試圖強制團隊遵循這些步驟，這樣的做法可能并不會非常有效。相反，應該提供一系列簡單的步驟，在其中使用能集 成大家當前使用的一系列工具且能與之良好協(xié)作的工具。

除了流程定義外，還要創(chuàng)建開發(fā)標準和約定。我們將首先完成這項任務，然后進行流程定義，以提出一些您可能希望在自己的項目開發(fā)流程定義中加入的要點。

什么是開發(fā)標準？

開 發(fā)標準提供一組可重用的常識性指導原則，開發(fā)人員在交付代碼模塊或組件時應該遵循這些指導原則。通過為項目定義一組初始標準和模板，可以向團隊傳達體系結 構、設計和實現(xiàn)指南。通過列出這些標準，還可確定開發(fā)人員在編寫各種模塊的代碼時的預期行為。沒有任何標準，或未在開發(fā)流程中包含任何初始想法，可能在部 署時或以后為各個模塊提供支持時出現(xiàn)混亂。

定義標準時，您需要符合 WebSphere Portal 提供的框架。您需要知道和理解各種即時可用的功能，以確保您的設計將與 WebSphere Portal 協(xié)同工作——而不是對其造成阻礙。如果不熟悉 WebSphere Portal，這些簡單的指導原則可在您開始首個門戶應用程序時提供幫助。

1. 從小項目開始。恰當?shù)卮_定項目范圍，避免一開始就著手構建大型門戶。通過不會變得過大而失控的初始項目獲得一些實際的經(jīng)驗。
2. 借助 WebSphere Portal 專家的力量。此人應該能在開發(fā)首個門戶的整個過程中提供持續(xù)的支持。即使您的團隊在使用 Java™ 方面經(jīng)驗豐富，WebSphere Portal 專家也能夠幫助您充分利用此框架和提供體系結構支持。

由于每個項目彼此不同，各自的要求差異很大，因此您需要將標準定義與環(huán)境定義分離開來。即，創(chuàng)建一個獨立的開發(fā)環(huán)境設置和配置 文檔來說明具體的配置信息，并在構建環(huán)境過程中對其進行維護。其中包括以下信息：

• 命名約定
• 錯誤和異常處理
• .war 和 .ear 文件結構
• 單元和功能測試指導原則
• 源代碼控制管理 (SCM) 流程指導原則
• 環(huán)境設置
• 具體庫或代碼順序

不過，不要局限于項目或開發(fā)工作的標準。沒有任何指導原則能處理可能遇到的所有情況。有時會遇到無法應用當前標準的情況。遇到這種情況時，請花一些時間深入分析一下情況，并進行以下工作。

• 就遇到的情況與團隊或項目負責人以及一起合作的其他開發(fā)人員進行溝通。如果問題很大，或您認為其他人可能遇到類似的情況，舉行一個簡短的會議來討論和制訂解決方案。
• 如果需要更改標準，或者在特殊情況下需要違反標準，請對其加以記錄！讓其他人知道指南中或代碼中違反標準的情況，并說明為什么
• 確定所采用的方法存在的任何問題和可能導致出現(xiàn)此情況的條件。
• 最后，通知標準文檔的所有者，讓他們知道您所遇到的情況。其他人可以從您的經(jīng)驗中獲益，且應該對指南進行更新。

標準為什么重要？

要提高開發(fā)流程的標準化程度的原因很多。您可能已經(jīng)遇到過需要復查或修改其他團隊成員編寫的代碼的情況。即使是最好的程序員，測試、復查和調試不遵循任何標準的代碼也是一項艱巨的任務。由于無法理解而剔除代碼并重新編寫的情況真是太多了。

遵循設計良好的編程標準能提高所交付的代碼內的一致性，并能夠提供更優(yōu)質的代碼，從而更便于其他開發(fā)人員理解和維護。設計良好且文檔完善的代碼可減少長期維護成本，還能減少將構件提供給其他團隊或團隊成員時的開銷。

分離關注點

我們所指的關注點 分離階段是指使用不同的環(huán)境控制組成部署發(fā)布版本的代碼流和其他文件。保持不同環(huán)境彼此獨立，且僅允許文件通過已定義的流程傳播，可幫助確保構建流程中的各個關鍵要素，如控制、可重復性和可靠性。

圖 1 顯示了開發(fā)工作站和最終生產環(huán)境之間的代碼流，我們以此來說明關注點分離的概念。如果您能理解這個流和環(huán)境分離，則可以在構建和部署流程進行期間對環(huán)境進行有效控制。

圖 1：構建和部署流程

開發(fā)團隊成員工作站

大 部分開發(fā)人員都在自己的本地工作站上工作。過去數(shù)年一直是這樣，目前并沒有需要改變這種方法的切實理由。當目標環(huán)境是 WebSphere Portal 時，使用 Rational Application Developer for WebSphere 及其 Portal Test Environment 的開發(fā)人員的效率會非常高。這些工具的設置過程非常簡單。還可以考慮使用包含目標環(huán)境的開發(fā)映像。這將允許編程人員在環(huán)境被破壞時進行重置。

在某些情況下，開發(fā)人員可能需要在自己的開發(fā)工作站上有完整的門戶安裝；例如，您可能希望使用正確的目錄服務器 (LDAP) 和數(shù)據(jù)庫來反映生產中使用的組件。構建安全組件的開發(fā)人員需要在其開發(fā)環(huán)境中設置與生產環(huán)境中類似的安全機制。

開發(fā)構建服務器

有些團隊對獨立構建服務器和獨立開發(fā)集成與測試的需求不甚明了。事實上，沒有硬性指導原則規(guī)定如何使用這些環(huán)境。我們將告訴您一種方法和這方面的相關建議，但您可以使用自己的策略來管理這些環(huán)境。

主 要的想法是將構建（或編譯）和打包軟件的流程從開發(fā)人員的工作臺分離出來。通常，構建服務器將是一臺物理計算機，但不是任何開發(fā)人員的工作站。不過，在小 型環(huán)境中，構建服務器也可以是位于開發(fā)人員工作站上的一個邏輯獨立體。關鍵是，要確保所有進入構建流程的組件都來自版本控制，而不是來自其他工作站或計算 機，以便確保每個構建操作都能從相同的單一源重復。

我們建議您嚴格執(zhí)行這個實踐。建立了此流程后，在出現(xiàn)構建操作時，通過源控制更新最新代碼或缺失的 jar 只需要很少的時間。

開發(fā)集成和測試環(huán)境

對開發(fā)集成環(huán)境采用類似的方法。除了通過 SCM 或構建存儲庫外，不應將任何代碼部署到此計算機上。開發(fā)人員需要訪問此計算機來檢查日志和查看結果；不過，永遠都不應該允許他們部署自己的代碼，因為這樣會導致以下問題：

1. 破壞可重復性。這會使得很難隨意重新創(chuàng)建部署或組件。
2. 當多人在此級別使用單臺計算機時，診斷沖突和環(huán)境故障會變得更為困難。

團隊對此方法的一個可能的擔心是，對環(huán)境施加約束可能會減緩開發(fā)團隊的工作進度。若要解決此問題，可以允許部分或全部開發(fā)人員在其本地工作站上安裝完整的門戶基礎設施，或者簡化構建流程來包含持續(xù)集成和部署，以便能自動構建和部署組件。

發(fā)布環(huán)境

發(fā) 布環(huán)境絕對遠離大部分團隊成員，不過部署和配置有這樣的需求時除外。通常需要多發(fā)布環(huán)境來避免進行多項測試工作時環(huán)境間出現(xiàn)沖突。質量保證 （Quality Assurance，QA）、用戶接受度測試（User Acceptance Testing，UAT）、性能和壓力測試都可能帶來需要進行評估的問題。

由于禁止開發(fā)人員訪問這些環(huán)境，因此需要采用某種方法來允許開發(fā)人員在不同的計算機上查看和配置日志，以便能夠進行問題診斷?？梢韵蛱囟ㄓ脩羰谟栌邢拊L問權限?；蛘撸梢栽试S在不同計算機上通過網(wǎng)頁訪問某些日志和屬性文件。

控制此流程

開發(fā)負責人應自己（或指定某人）控制源代碼管理流程，這樣才是團隊管理流程，而不是流程管理團隊。此人要確保簽入所有代碼，并已準備好進行構建和部署步驟。通過使用并理解組成當前代碼庫的所有組件，此人可以和其他團隊就組件如何一起工作以及如何部署進行溝通。

回頁首

實現(xiàn)構建流程

在 很多 WebSphere Portal 項目計劃中，“構建”通常被標識為項目計劃上的單條線或任務。在有些項目計劃中，甚至不將構建定義為任務，因為有些項目經(jīng)理將其視為開發(fā)人員的日常工作的 一部分。構建是為門戶項目創(chuàng)建門戶構件的過程。WebSphere Portal 最佳實踐認為，構建流程是門戶項目的發(fā)布周期中一項重要的活動。

什么是構建流程？

WebSphere Portal 既是應用服務器，也是應用程序框架。它允許開發(fā)人員創(chuàng)建自己的代碼（針對此框架進行了自定義）并將代碼部署到 WebSphere Portal，以創(chuàng)建一個新門戶網(wǎng)站。構建流程會對代碼進行編譯并生成可部署程序包（其中包含 WebSphere Portal 項目解決方案構件）。

通 過定義構建流程，可確保每次團隊生成可部署程序包時，將在正確的級別進行組合，流程能以完全相同的方式進行。整個構建流程應該是可重復的和可跟蹤的。盡可 能詳細地對構建流程中的確切步驟順序進行確定、記錄和自動化。由于構建流程在較大的門戶項目中會變得比較復雜，因此更有必要實現(xiàn)這樣的標準化。

明確定義的構建流程可幫助消除開發(fā)、集成、過渡和生產環(huán)境間潛在的差距。您可以使用構建流程來將門戶構件從一個環(huán)境遷移到另一個環(huán)境。它還可以消除與編譯、類路徑或屬性相關的很多問題；這些問題可能會耗費大量的項目時間和資金。

您可以定義兩種類型的構建流程：

1. 本地構建：在這種情況中，開發(fā)人員將使用 Rational Application Developer 或 Ant 或 Maven 腳本在自己的工作站上構建代碼。然后開發(fā)人員使用測試環(huán)境對代碼進行測試。
2. 構建服務器構建：構建服務器從版本控制系統(tǒng)提取代碼，然后使用構建管理人員創(chuàng)建的腳本進行構建。此流程還將相應地構建任何依賴性 JAR 文件和包。

創(chuàng)建構建流程涉及到以下活動：

• 定義此構建流程的步驟
• 定義作為此構建流程的輸入的源代碼
• 定義此構建流程生成的構件
• 創(chuàng)建執(zhí)行此構建流程的工具

構建管理人員的任務是什么

在很多門戶項目中，開發(fā)團隊僅由代碼開發(fā)人員組成。在接近開發(fā)階段尾聲時，開發(fā)人員將創(chuàng)建 Ant 或 Maven 腳本來編譯代碼，并生成門戶構件（如 Portlet 的 war 文件和主題和皮膚的 zip 文件）。

您可以指定團隊中兩個人分別擔任構建管理人員（或代碼維護人員）和部署管理人員（或發(fā)布管理人員）。對于大型門戶項目，構建管理人員和部署管理人員都是開發(fā)團隊中非常重要的角色。根據(jù)項目的規(guī)模不同，可以讓一個人同時擔任這兩個角色。

構建管理人員負責維護代碼，運行構建流程，還要確保每次使用完全相同的步驟生成門戶構件。

構建組件與打包

良 好的構建流程應定義要生成哪些構件。這些構件可以為組件（如 war 文件或 zip 文件），也可以為 wps.ear 包中的文件。為了確定一個構建流程來生成這些不同類型的構件，需要對您的門戶解決方案的設計進行仔細的研究。構建 Portlet 的方式可能會與構建門戶可能需要的其他構件的方式不同。請參見“下載”部分，其中提供了使用 Rational Application Developer 項目結構來構建 Portlet 的 Maven 和 Ant 示例腳本。

和其他團隊協(xié)作

開發(fā)團隊完成了其代碼開發(fā)工作后，構建管理人員將與開發(fā)團隊和部署團隊密切合作，以生成門戶構件并將其部署到門戶環(huán)境中。構建管理人員將運行構建流程來生成門戶構件，部署管理人員則將這些構件部署到開發(fā)、集成、過渡和生產環(huán)境中。

當開發(fā)團隊希望將其新代碼部署到開發(fā)環(huán)境中時，會向構建管理人員發(fā)送構建請求。此構建請求指定以下內容：

1. 要構建 SCM 中的哪個項目
2. 這些項目的版本
3. 目標環(huán)境
4. 構建應完成的時間限制

如圖 2 中所示：

1. 構建管理人員使用構建工具生成門戶構件
2. 構件管理人員向開發(fā)團隊通知構建流程的狀態(tài)
3. 構建管理人員向部署管理人員發(fā)送部署請求，指示門戶構件的可用性，并請求將其部署到指定的目標環(huán)境中。
4. 當部署完成時，部署管理人員通知構建管理人員。

圖 2：與項目團隊協(xié)作

隨著開發(fā)工作逐漸接近門戶測試階段，構建管理人員可以創(chuàng)建每日構建并將構件部署到開發(fā)人員的開發(fā)環(huán)境中。構建管理人員應該每周（或更頻繁）對更為成熟的標記代碼進行相同的工作，將其部署到測試人員的集成環(huán)境中。

選取構建工具

由 于存在很多選擇，選擇構建工具也可能成為一個比較麻煩的任務?？梢赃x擇各種開放源代碼工具，如 Ant、Maven 或構建服務器的 Cruise Control。這些都是 Apache 的開放源代碼項目。為了給環(huán)境選取正確的工具，將需要進行一定的研究工作；在很多情況下，這些工具可以協(xié)同工作，從而提供額外的功能。

以下是 Julien Dubois 在“Master and Commander”一文中所做的一個簡單比較。

Ant 可為您提供靈活性，而 Maven 則可提供更多的結構和良好的依賴關系管理?？梢栽?Ant 內使用部分 Maven 功能，反之亦然。

可以將 Ant 或 Maven 與 CruiseControl 結合使用，從而實現(xiàn)構建過程的自動化。如果有 Ant，則可以從 Maven 調用 Ant?？赏ㄟ^一些任務從 Ant 使用 Maven 功能，反之亦然。

CruiseControl 允許對構建進行計劃安排——可以在夜間或任何特定時間進行。因此可以節(jié)約一定時間，特別在構建需求更頻繁的項目初始階段更是如此。這是一個用于持續(xù)構建流程的框架。通過使用 CruiseControl，可以進行以下工作：

1. 從版本控制系統(tǒng)提取源代碼
2. 使用 Maven 或 Ant 將源代碼構建為門戶構件，如 war、zip 和其他文件
3. 將這些文件放入部署區(qū)域
4. 部署構件
5. 將文件保存回 SCM，并為其指定一個新版本標簽或標記
6. 運行構件驗證測試
7. 發(fā)送電子郵件通知
8. 通過使用 Maven，您可以生成報告并發(fā)送有關構建狀態(tài)的電子郵件。

的 AntHill 是使用 Ant 的另一個構建工具（需要繳納少量許可費用），非常易于安裝和使用。

構建過程中要考慮的構件

以下是在創(chuàng)建構建和部署腳本時要考慮的一些構件。

1. Portlet
2. 皮膚
3. 主題
4. 屬性文件
5. NLS 資源包
6. <PortalServer>/shared/app/config/services 下的配置文件
7. 共享庫
8. XMLAccess 腳本
9. Web 文件

版本控制

為了提供可跟蹤性和故障轉移恢復，在將門戶構件放入部署區(qū)域后，還應該將其作為 新版本保存到 SCM 中。您可以從 SCM 內跟蹤這些門戶構件的構建歷史。

您要進行的最重要決策之一就是，您的團隊將使用哪個源代碼管理系統(tǒng)。有很多系統(tǒng)可用，您的組織或公司標準可能會規(guī)定使用哪個系統(tǒng)。

有兩種完全不同的源代碼管理系統(tǒng)。

• 簽入/簽出，如 Visual Source Safe、CMVS 或 Rational ClearCase。
• 持續(xù)流；如 Concurrent Versioning System (CVS) 使用合并類型的系統(tǒng)來提交新代碼，而不采用簽入/簽出方式。開發(fā)人員使用以下流程：
• 復制——獲取代碼最新副本的本地版本。
• 更改——進行必要的更改。
• 合并——提交更改并將其與現(xiàn)有代碼合并。

CVS 或 Concurrent Versioning System 是一個可行的選擇，特別在沒有其他 SCM 系統(tǒng)供團隊使用時更是如此。CVS 是免費提供的開放源代碼系統(tǒng)，在開發(fā)領域得到了廣泛的接受和使用。管理人員可能遇到的一個潛在缺陷是 CVS 內缺乏文件鎖定功能。根據(jù)您的觀點或管理風格不同，既可以將其視為優(yōu)點，也可以將其視為缺陷。對于能有效溝通、組織良好的團隊，缺少鎖定不是問題。

另一個可能的問題是，由于 CVS 并未由某個公司在市場上正式銷售，因此缺少正式的支持服務。這可以作為不選擇此工具的一個有效理由；不過，由于開放源代碼社區(qū)廣泛使用此工具，因此能為您遇到的很多問題提供強大的技術支持。

按 照開發(fā)社區(qū)推薦的方式使用 CVS 還可幫助緩解各種問題。使用 CVS 的優(yōu)勢之一在于其提供了一些免費的外接程序工具。例如，CVSWeb 是基于 Web 的接口，允許非 CVS 用戶直接查看存儲庫，而無需使用客戶機軟件或開發(fā)環(huán)境的插件（將在下面進行說明）。

下面的圖 5 顯示了如何將 CVS 集成到您的 Eclipse 或 RAD 開發(fā)環(huán)境中。

圖 5：用于 Rational Application Developer 的 CVS 插件

隨 Rational Application 安裝了一個功能齊全的 CVS 插件。可以在 RAD 的 Team 透視圖中時設置此插件，這將允許開發(fā)人員在進行開發(fā)時方便地查看、提取和合并代碼段。這個功能對于定義良好且易于使用的構建和部署流程非常重要。當向開發(fā) 人員提供了簡單的 SCM 集成流程時，就會減少他們嘗試走捷徑的可能性，從而避免打亂團隊的流程和控制。

構建失敗時

并不能保證每個構建都會完全成功。構建工具執(zhí)行后，構建管理人員將查看構建工具日志文件，以確定構建過程是否完全成功。如果構建失敗，則要嘗試確定失敗的原因。大部分構建工具允許將構建報告以電子郵件的方式發(fā)送出去。

如果失敗是由于源代碼導致的，構建管理人員可以向開發(fā)團隊或負責修復構建的人員發(fā)送請求。開發(fā)團隊修復了代碼后，構建管理人員將重新運行構建流程。將重復此過程，直到構建完全成功為止。

應用緊急修復程序

在某些情況下，可能需要向構建構件應用緊急修補程序，以便能繼續(xù)進行測試或保證按時投入生產環(huán)境。將緊急修復流程作為構建流程文檔的一部分清楚地進行記錄。

構建流程總結

總的說來，構建流程是門戶項目發(fā)布周期中的一個重要活動。構建管理人員應是開發(fā)團隊中的成員。應對構建流程進行定義，并應選擇（或創(chuàng)建）構建工具來實現(xiàn)流程的自動化。

如果團隊遵循所定義的構建流程，并使用構建工具進行標準化，則可以避免很多來自構建流程的意外問題。在構建流程上花費的時間和資金將通過消除測試期間的其他意外問題而得到回報。

回頁首

部署門戶

在 很大程度上，門戶是一個復雜的 J2EE 應用程序，其中可以包括 Web 模塊、ear 文件、jar、屬性文件和其他資產。每個 Portlet 都是一個實現(xiàn)特定功能的獨立 Web 應用程序，可以作為獨立的單元進行操作。通過進行恰當?shù)脑O計，可以將這些 Portlet 組合為組合應用程序。

在很多情況下，由于 WebSphere Portal 提供了額外的框架，而使得門戶環(huán)境甚至會比類似的 J2EE 環(huán)境還要復雜。您需要在門戶數(shù)據(jù)庫中注冊某些特定于門戶的組件，以便能夠對其進行管理，并向環(huán)境提供。

WPS.ear 是核心 WebSphere Portal 包，作為 Web 容器中的獨立 Web 應用程序運行。其中包含門戶的大部分基本功能，包括一些重要的集成功能，如菜單和外觀。

部署 Portlet

可 以采用多種方式安裝 Portlet，如使用門戶管理界面或使用 XML Access。由于最終的目標是實現(xiàn)部署門戶資源和組件的流程的自動化，因此需要采用腳本對其進行部署。您可以對 Portlet 進行分析，并基于 Portlet 內的 portlet.xml 文件生成 XMLAccess 部署腳本。

請參見 Reference: Sample XML configuration files section of the WebSphere Portal InfoCenter 中提供的大量示例腳本。您可以選擇并修改適合您的部署需求的腳本。

然后，可以使用經(jīng)過修改的腳本來安裝 .war 文件。不過，您還需要使用某個自動化方案來構建和部署此腳本。為了自動生成 Portlet，您可以使用清單 1 中的腳本，同時通過自定義 Ant 任務檢查 portlet.xml 并使用一些模板屬性對其進行更新。

清單 1. 用于構建 Portlet 的示例 Ant 腳本

				
<?xml version="1.0" encoding="UTF-8"?>
<project name="xMethodsTempPortlet" default="main" basedir=".">
<project name="xMethodsTempPortlet" default="main" basedir=".">
<property name="name" value="${ant.project.name}" />
<property name="deployDir" location="dist" />  
<property name="dist.dir" location="${deployDir}" />
<property name="dist.download.dir" location="${dist.dir}/download" />
 <target name="main">
	<echo message="Starting build process...." />
	<antcall target="compile" />
	<antcall target="archive" />
</target>
<target name="compile">
	<property name="build. compiler" value="modern" />
	<javac srcdir="../Java Source" >
		<classpath >
		<pathelement location="../../PortalMain/BaseLibraries/lib/j2ee.jar" />
		<pathelement location="../../PortalMain/BaseLibraries/lib/websphere.jar" />
		</classpath>
	</javac>
</target>
<target name="archive" depends="compile">
	<tstamp><format property="build.time" pattern="MM/dd/yyyy hh:mm aa" /></tstamp> 
    	<filter filtersfile="template.properties"/>
 	<filter token="buildinfo" value="(build date: ${build.time})"/>
	<copy file="portlet_template.xml" toFile="..\Web Content\WEB-INF\portlet.xml" 
	overwrite="yes" filtering="true" />
	<mkdir dir="${dist.download.dir}" />
	  <zip zipfile="${dist.download.dir}/${name}-${version}.war" basedir="..\Web Content"/>
</target>	
</project>
	

可以通過此示例來將 Portlet 的名稱替換為每個構建的版本號。在測試期間，開發(fā)人員和測試人員可以使用這個強大的方法來確定其正在使用的版本。此示例包含構建的時間戳，以便確定其創(chuàng)建時間。

				
Template.properties
		
version = 1.0.0.29
	

此模板屬性文件相當簡單，只是一個希望在篩選操作期間替換的屬性列表。還可以使用 Ant 腳本安裝 Portlet。

				
<?xml version="1.0" encoding="UTF-8"?>
<project name="xMethodsTemp Portlet" default="main" basedir=".">
<property name="deployDir" location="dist" />  <!-- passed in by Anthill -->
<property name="dist.dir" location="${deployDir}" />
 <property name="dist.download.dir" location="${dist.dir}/download" />
<target name="main">
<antcall target="deploy" />
</target>
<target name="deploy">
  <echo message="Starting deploy to test..."/>
  <java classname="XmlAccess">
    <arg value="C:\anthill\work\xMethodsTempPortlet\build\xmlAccessUpdatePortlet.xml"/>
    <arg value="wpsadmin:wpsadmin"/>
    <arg value="wpsdev/wps/config"/>
    <arg value="2"/>
<classpath >
<pathelement location="C:\WebSphere\PortalServer\bin\XmlAccess.jar" />
</classpath>   
  </java>
  <echo message="deploy complete!"/>  
</target>
</project>
<!--arg value="C:\anthill\work\xMethodsTempPortlet\build\xmlAccessUpdatePortlet.xml"/-->
	

此示例調用 XmlAccess 類，并同時傳入所需的參數(shù)。用于更新 Portlet 的 xml 文件應隨 Portlet 一起提供，可以作為版本控制的一部分進行保存。

部署主題和皮膚

可以將 WPS.war 文件作為 .ear 文件部署到服務器。通過這樣的方式部署主題和皮膚比直接將其復制到服務器更為安全。

門戶主題是基于 JSP 和 CSS 文件結構的文件系統(tǒng)。創(chuàng)建門戶主題首先要理解其文件系統(tǒng)。WPS.ear 是 WebSphere Application Server 下的一個企業(yè)應用程序，因此您可以在與以下所示類似的服務器文件系統(tǒng)中找到該文件：

在此文件系統(tǒng)中，可以找到 themes 和 skins 文件夾，這兩個文件夾下均包含有 markups 文件夾。

之所以作為 EAR 部署，主要是為了跨系統(tǒng)實現(xiàn)源代碼控制、可重復性和一致性。建立了系統(tǒng)后，可以更方便地在部署期間執(zhí)行此步驟。

可以采用若干其他方法部署 EJB：

• 通過應用服務器管理控制臺。您可以安裝、修改或卸載企業(yè)應用程序存檔（Enterprise Application Archive，EAR）文件。
• 通過使用 wsadmin 接口的腳本

有關安裝 ear 文件的基本腳本方法，可以使用以下命令：

此命令將安裝 wps.ear 文件。

您將在下面的部分中了解關于此方法的更多信息。

處理靜態(tài)文件

按 照傳統(tǒng)的做法，希望提高性能的網(wǎng)站會將靜態(tài)文件移動到 Web 服務器層，以減少應用服務器上的負載。雖然這個做法不錯，但對于嘗試以這種方式構建應用程序的開發(fā)人員卻有些困難。Web 服務器插件包含內置 ESI 處理器，該處理器將緩存整個頁以及必要的片段，具有較高的緩存命中率。可以將靜態(tài)文件和 Portlet 打包到一起，同時仍然能夠獲得將其移動到 HTTP 服務器時的性能優(yōu)勢。ESI 處理器實現(xiàn)的緩存是內存內緩存?？梢酝ㄟ^ WebSphere Web 服務器插件配置文件 plugin-cfg.xml 對此緩存處理器進行配置。

<?xml version-"1.0"?> <Config> 
<Property Name="esiEnable" Value="true"/>
<Property Name="esiMaxCacheSize" Value="1024"/>
<Property Name="esiInvalidationMonitor" Value="false"/>
	

在集群環(huán)境中部署 Portlet

對 于最初發(fā)布的 WebSphere Portal V5，將組件部署到集群環(huán)境需要執(zhí)行若干步驟。由于 XMLAccess 更新門戶數(shù)據(jù)庫的方式，如果僅在多個可能位置中的一個位置更新代碼，集群環(huán)境中可能會出現(xiàn)沖突問題。很多生產環(huán)境都優(yōu)先采用集群方法來提供更高的性能和服 務器出現(xiàn)故障時的故障轉移功能。WebSphere Portal 的后續(xù)版本和修復程序包已修復了其中的一些問題。在本文中，我們假定部署流中出現(xiàn)了最糟糕的情況，以便能涵蓋所有需求。

使用 XMLAccess 安裝或更新 WAR 文件。

1. 名為 XMLAccess 的門戶部署工具是基于 Java 的工具，將使用 XML 對 WebSphere Portal 文件系統(tǒng)和數(shù)據(jù)庫進行必要的更改。它可支持門戶管理和維護所需的多種任務。

   您需要在所有標記中將 active 屬性設置為 false，以防止在同步節(jié)點并啟動應用程序前出現(xiàn)嘗試操作所導致的警告。在包含 WAR 文件的路徑的 URL 標記中指定要安裝的 WAR 文件的路徑。

2. 等待集群中的節(jié)點同步 Portlet。

   部署了單個 Portlet 或一組 Portlet 后，會將其標記為非活動狀態(tài)，直到節(jié)點同步了集群內的所有階段，可以激活所有 Portlet 為止。

   可以查看不同服務器上的節(jié)點代理的 system.out 日志，以查看同步過程的執(zhí)行情況。這個過程不會持續(xù)太長時間，但它是部署流程中一個必需的步驟，大型的部署活動可能會導致環(huán)境較長時間停機。

3. 現(xiàn)在使用 XMLAccess 激活 Portlet。
4. 修改部署腳本，以激活所有 Portlet，然后再次運行。需要執(zhí)行以下操作：
5. 修改腳本，以刪除所有 Portlet 的 URL。
6. 在所有 Web 應用程序上將 activate 設置為 true。

運行經(jīng)過修改的腳本時（完成了初始部署和同步后），門戶將激活系統(tǒng)上的所有 Portlet 并進行必要的頁面填充操作。

在集群環(huán)境中部署主題和皮膚

在 集群環(huán)境中，必須從 Deployment Manager 導出門戶 EAR 文件，使用新主題和皮膚目錄更新 EAR 文件，然后將企業(yè)應用程序文件重新導入到 Deployment Manager 計算單元。如果您使用的是獨立門戶服務器，則請使用應用服務器代替 Deployment Manager。有關詳細信息，請參見 InfoCenter under Deploying customized themes and skins。

使用共享庫

可以使用共享庫在門戶內不同組件或 Portlet 間共享資源。這些共享庫通常是在應用程序設計階段確定的（在此階段確定需要跨多個 Portlet 或組件共享哪些組件）。使用共享庫時，您需要在應用服務器內設置變量，以允許在必要時加載這些共享庫。

要部署共享庫，請執(zhí)行下列操作：

1. 將庫文件復制到正確的 WebSphere 目錄
2. 使用 wsadmin 在 WebSphere 內安裝庫。

或者，將 .jar 文件直接放入 /PortalServer/shared/app 目錄。如果要為這些文件使用獨立目錄，則請使用管理控制臺或 wsadmin 配置命令在服務器中創(chuàng)建共享庫，例如：

$AdminConfig create Library $server {{name myLibrary} {classPath c:/WebSphere/PortalServer/shared/app/myLibraryClasspath}}

計劃部署和系統(tǒng)停機

縮 短站點的停機時間是一個常見問題；不過，計劃的維護停機時間卻是一件必要的“壞事”。管理人員理解了這一點后，一切就會變得更加簡單了。站點可能沒有計劃 停機；不過，可能會因此招致大量硬件投資，因為您需要準備兩套基礎設施，以便在升級一套系統(tǒng)的同時另一套系統(tǒng)能繼續(xù)保持所需的用戶負載處理水平。

如果您的組織不準備承擔高標準基礎設施的相關成本，則現(xiàn)在務必與管理人員和最終用戶交流或討論對計劃停機的需求，使其在投入使用后成為一項日常事務。

如果流程設計良好，且團隊工作同步，則經(jīng)?？梢詫⑼C時間降到最低水平?？赡軙驗槿舾稍蛐枰C：

• 升級基礎設施組件和操作系統(tǒng)
• 需要部署新構建版本

在有些情況下，會在維護期間同時進行上述兩項工作。如果您有多個發(fā)布環(huán)境，就可以在預生產環(huán)境中進行維護工作，以盡可能減少生產部署期間的風險。

回頁首

管理發(fā)布環(huán)境

發(fā)布會涉及到能在門戶中部署和配置的各種各樣的構件。發(fā)布版本可以是配置更改、Portlet 更新、用于安裝新門戶的完整程序包和任何更改組合。團隊間的溝通和跟蹤對成功維護組織中的每個環(huán)境非常關鍵。

發(fā) 布版本具有編號，通常的形式為主版本、次版本、修復程序編號并加上點號，如 2.1.0.1。這些數(shù)字可能表示主版本、次版本和版本內不同類型的修復程序。您將需要對這些發(fā)布版本進行記錄；包括版本中包含的內容以及部署說明。您需 要跟蹤發(fā)布版本在以下每個環(huán)境中的情況：開發(fā)、集成、操作接受度測試、用戶接受度測試、過渡和生產環(huán)境。

在發(fā)布計劃中，請確保包含維護窗口、備份、部署時間、擱置時間和測試的相關內容。請自動化安裝，以盡可能減少人為錯誤；請包含數(shù)據(jù)庫更新、訪問控制、皮膚、主題和頁面更新。

回頁首

處理失敗部署和回滾

經(jīng)過全面測試的備份和恢復過程對任何生產環(huán)境都十分重要。WebSphere Portal 也不例外。請開發(fā)并測試（在測試環(huán)境中進行）完整的災難恢復策略和方法。經(jīng)過驗證后，應將這些過程實現(xiàn)到 WebSphere Portal 生產環(huán)境中。

雖然這些不是用于備份和恢復的詳細過程，但提供了進行 WebSphere Portal 備份和恢復的一種方法，可以與公司現(xiàn)有的災難恢復過程一起實現(xiàn)。

從 失敗的部署回滾，或者新代碼存在問題，都會使得使用者面臨一定的困難。利用一些 WebSphere Portal 功能可簡化出錯時應進行的工作。由于遵循的是以前發(fā)布版本的已定義構建和部署流程，最簡單的“回滾”方法就是重新部署上一個發(fā)布版本。這可能并不總是最簡 潔的方法，但對于大部分情況，這將確保在門戶中重新安裝最新的有效代碼包。

目前，確保全面回滾能力的唯一方法是在部署前進行完整的文件系統(tǒng)和數(shù)據(jù)庫備份。這將確保文件系統(tǒng)的正確性和恢復數(shù)據(jù)庫備份中任何新的配置更改。還可以在 XML 腳本中使用“事務性”來確保腳本以“All or Nothing”模式運行。

回頁首

結束語

本文提供了有關為門戶項目創(chuàng)建構建和部署流程的觀點和建議步驟。本文的主要目的在于讓您認識到，對此流程進行考慮是非常值得的。我們刻意在較高的抽象層次進行討論，讓您自己確定適合自己的環(huán)境的相關細節(jié)。我們專門提供了一些示例和腳本，以幫助您盡快上手。

請 牢記所討論的這一過程中使用的一些指導原則。保持簡單，并在項目中盡早開始相關工作。即使不會立即構建任何東西，也請啟動腳本并持續(xù)運行，直到其正常工作 為止。腳本必須隨著項目的進行而持續(xù)加以改進，只有這樣，才不會在項目結束時發(fā)現(xiàn)有一大堆讓人生畏的創(chuàng)建任務需要完成。如果沒有配備構建服務器，可以進行 簡單的腳本測試，提取必要的代碼組件來運行腳本。如果腳本不能正常運行，則可能相對路徑存在問題，需要進行修復。最后，不要嘗試設計一個執(zhí)行您認為需要完 成的所有任務的流程。讓系統(tǒng)隨著您的需求逐漸發(fā)展，而不要嘗試立即形成整個流程。

本文并沒有詳細討論整個構建、部署和遷移流程 (這對項目的成功非常必要)。例如，我們并未討論如何在門戶內構建和傳輸頁面和 Portlet 布局。此步驟之所以重要，是因為您并不一定希望管理員在不進行更為正式的 QA 和性能測試流程來確定任何更改的影響的情況下在生產環(huán)境中更改布局。具有針對所有組件的發(fā)布策略可讓您快速從環(huán)境內可能出現(xiàn)的異常情況中恢復。

回頁首

下載

描述	名字	大小	下載方法
Portal build samples	portalbuild-samples.zip	36KB	FTP|HTTP

	關于下載方法的信息			Get Adobe® Reader®

回頁首

參考資料

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文 。
  
  
• An introduction to Maven 2 說明了如何優(yōu)化 Java 構建流程。
  
  
• Master and Commander (Maven) 了解 Ant 和 Maven 以及它們與 J2EE 構建的關系。
  
  
• Automate your build process using Java and Ant
  
  
• WebSphere Portal in Action：參閱 Joey Bernal 在 developerWorks 上的博客。
  
  
• developerWorks WebSphere Portal 專區(qū)：獲得更多的資源，以幫助您開發(fā)門戶和 Portlet。
  
  
• WebSphere Portal 產品文檔：訪問所有當前產品文檔，包括所有 WebSphere Portal 版本的 InfoCenter、發(fā)布說明和自述文件。
  
  

• 使用 Rational Application Developer。

回頁首

作者簡介

		Anthony (Joey) Bernal 是 IBM Software Services for Lotus (ISSL) 的高級 IT 咨詢專家。從最初的 1.1 版開始他就從事 WebSphere Portal 方面的工作，在設計和開發(fā)門戶應用程序方面有著豐富的經(jīng)驗，他已經(jīng)用 IBM WebSphere Portal 實施了許多項目。Joey 還是 WebSphere Portal 及其相關技術方面的一位杰出作家、演說家和講師。他是 Programming Portlets 一書的合著者。

		Varad Ramamoorthy 是 IBM Software Services for Lotus 的 IT 咨詢專家。從最初的 1.1 版起就開始從事 WebSphere Portal 方面的工作，一直在用他自己的專業(yè)知識來幫助解決客戶文件。他發(fā)表了很多有關 WebSphere Portal 及相關技術的文章。

		Yixing Gong 是 IBM Global Business Services 的門戶、內容和電子商務方面的 IBM 認證高級 IT 專家。他已在 IBM 工作了 11 年，主要從事 WebSphere Application Server 上的 Web 應用程序以及 WebSphere Portal 上的門戶站點的體系結構設計和開發(fā)工作。從推出 WebSphere Portal 的最初版本開始，他就開始向美國全國的客戶提供有關 WebSphere Portal 的咨詢服務。

		John Barron 是 IBM Global Business Services 的一名高級 IT 專家。他擁有 22 年 IT 行業(yè)系統(tǒng)和軟件工程方面的經(jīng)驗。從最初的 1.1 版開始，他就在使用 WebSphere Portal，在配置、集成和維護門戶應用程序方面具有廣泛背景。

		Julia Weatherby 是 IBM Software Services for WebSphere 的一名 IT 專家。她有 9 年使用 IBM 軟件系列中的各種產品的經(jīng)驗，包括實現(xiàn) WebSphere Application Server、WebSphere Portal 以及為 IBM 的客戶實現(xiàn)相關技術等。