ClearQuest管理和執行ClearCase中的軟件部署

2019-11-18 13:08:59

字體：大中小

來源：轉載

供稿：網友

　　IBM Rational ClearQuest雖然本身不是一個軟件部署工具，但是通過協助記錄日志并跟蹤部署歷史記錄和工件，消除手工步驟，將項目協調和時間安排連接在一起，可以幫助使部署過程自動化，并治理發布的工作流。請點擊文章頂部或底部的討論，參與論壇討論，與其他讀者分享您對本文的看法。
　　
　　概述
　　此技術文章是面向從事軟件構造和發布工作的專業人員以及變更和配置治理經理的，他們可能想要創建一個更正式的自動化部署過程。假定已經對IBM? Rational? ClearQuest?、軟件部署和統一變更治理過程（UCM）有了一個基本的理解。
　　
　　背景知識－－部署
　　在軟件工程，以及Rational統一過程?（RUP?）中，部署的目的是將一個系統轉移到其用戶或利益相關者。在部署過程中所包括的是一組可以說明系統目的工件，用戶或維護/治理培訓材料，安裝過程，資料單，當然還有可執行軟件自身。
　　
　　部署過程需要是可重現的、可控的和可跟蹤的。為了達到這些目標，需要考慮以下關于工件部署的步驟。
　　
　　工件必須被置于配置治理控制之下，并且已經基線化
　　假如需要，軟件工件必須按照一種可控的和可重現的方式被構造（也就是被編譯，等等）
　　軟件工件必須被“打包”，并預備好進行安裝
　　這可以是一個“zip”文件，文件被寫到一張只讀光盤上，或者通過創建一個Tivoli包來進行
　　工件必須被部署或轉移到目標環境
　　為了正確的執行，工件必須被安裝和配置
　　必須有文檔工件來具體說明此過程中的步驟，創建一個工件的資料清單，并描述在工件中所發生的變更。
　　假如部署、安裝和/或配置過程要碰到問題，必須要有返回過程和程序
　　許多組織需要驗證和確認被部署到一個產品服務器環境下的正確工件。此外，他們必須能夠返回到源代碼工件來跟蹤這些工件，并提供具體說明所有這些變化和核準這些變化的人員的文檔。為了完全滿足這些需求，以上步驟必須按照一種規范的和自動化的過程來進行。這有助于減少現有項目資源上的治理費用的數量，也可以使得過程變得更為可重現。
　　
　　ClearCase UCM和基線
　　請參見Jim Tykal的技術文章“在UCM中使用復合基線的最佳實踐可以得到UCM（統一變更治理）以及基線和復合基線概念的更多具體內容。在那篇文檔中具體列出的這些術語和概念將會在本文的整個文檔中被使用。
　　
　　使用ClearCase創建和執行軟件部署
　　在此案例研究中，IBM? Rational? ClearCase?正在被顧客用來進行UCM方式的軟件配置治理。所有源代碼工件按照ClearQuest活動進行checked out和checked in。java代碼使用ANT來進行構造和打包。在構造過程期間，創建UCM基線。
　　
　　配置治理團隊已經努力工作來自動化構造和部署過程，以增強質量，增加工作效率，并為其他項目構建一個可使用的框架。為了增加通告和信息，構造和部署腳本與一個Web入口集成在一起，確定部署的特定狀態（紅色－－失敗的部署，黃色－－進行中的部署，綠色－－成功的部署）和相關聯的ClearCase基線標簽。批準過程以及記錄和跟蹤所有必需的部署歷史和批準工件的要求，對于腳本化來說太多了，假如不創建一個定制的軟件工具很難進行處理。即使對于最熱心的工具人員，這項任務也會成為一個挑戰。然而，顧客非常幸運，配置治理團隊成員充分理解到有更好的方式治理此工作流程和必需的工件。
　　
　　使用ClearQuest治理軟件部署
　　首先，讓我們直接設置一下記錄。ClearQuest不是一個軟件部署工具。軟件部署可以手動執行（例如，使用FTP命令），可以被腳本化，或者可以通過企業級工具來實施，例如IBM Tivoli Configuration Manager。
　　
　　對許多顧客來說，對于軟件部署的最好的解決方案是使過程腳本化。這提高了現有項目團隊成員的知識，相對更加輕易設置和維護，并且可以作為與軟件構造中所使用的相同過程或工具類型的一個延續。腳本的使用使得過程可以重現，并且極大地減少了在任何手工過程中所固有的人為錯誤的風險。
　　
　　在一個顧客的案例中，他們的構造和部署過程如下：
　　
　　創建構造和部署代碼所需的腳本
　　構造軟件，并基線化ClearCase中的代碼
　　將代碼復制或FTP到開發測試環境中
　　在成功的單元測試和一些非正式的集成測試之后，為集成測試預備好代碼
　　發送電子郵件到集成測試組成員，說明代碼預備好進行集成“I”測試，并確定何時代碼應當被部署
　　集成測試組成員通過電子郵件響應，說明他們何時預備好
　　軟件被部署到“I”環境
　　執行集成測試
　　當集成測試完成和成功后，電子郵件被發送到質量保證測試團隊，說明代碼預備好質量“Q”測試環境
　　質量保證團隊使用電子郵件響應，說明接受和部署時機預備好
　　相同的過程一直持續到部署到產品，或者“P”環境。
　　在上面的工作流中，有幾個步驟將需要手工工作和協調。例如，盡管被發送給測試團隊的電子郵件可以使用腳本進行自動化，但是監測來自測試團隊的電子郵件的響應現在還是一項手工工作。閱讀電子郵件響應，確定團隊是否預備好新軟件的過程，以及軟件何時應當被部署到目標環境中，要花費時間和大量的通信。在此過程中，至少對于某些顧客，此通信過程可以被打斷－－或者整個中止。隨著部署工件接近產品預備就緒階段，更多的正式批準是必不可少的，并且對更好的計劃和溝通部署的需要也是必要的。
　　
　　進入ClearQuest
　　顧客將ClearQuest用在Microsoft Windows工作站上的所有軟件開發上已經大約一年了。所有軟件變更請求和問題都存儲在ClearQuest中。
　　
　　對于部署跟蹤的ClearQuest實施相對比較簡單。創建用于跟蹤部署的記錄，一個記錄類型為批準記錄，一個記錄類型為應用程序，還有一個記錄類型為角色－－這樣就預備好了解決方案的基礎。有一些其它記錄類型，可以使用戶界面、選擇和跟蹤過程變得更輕易一些，這些記錄類型將在稍后論述。
　　
　　圖1顯示了不同的記錄類型之間的關系。UCM_PRoject記錄是一種被使用的記錄類型，是由ClearQuest框產生的。其它記錄類型是為此實施特定創建的。
　　　 ClearQuest治理和執行ClearCase中的軟件部署

　　圖1：不同記錄類型之間的關系
　　
　　為描述整個環境，我們將以分塊開始，逐步建立部署記錄。
　　
　　TIQP_Environment記錄用于存儲有關不同服務器設備的信息。在此非凡的顧客測試環境中，每個環境包括一個用于一個非凡應用程序的服務器（至少在本方案開發期間的初始階段中）。一個服務器可能作為多個應用程序的宿主，但是一個應用程序只能位于一個服務器。TIQP_Environment記錄確定服務器的名字、IP地址、部署環境的類型（T：開發者測試；I：集成測試；Q：質量保證和性能測試；或P：產品），以及幾個其它字段。
　　
　　role記錄類型用于為每個應用程序確定一個非凡的用戶“角色”。每個應用程序定義的角色至少包括一個應用程序或程序經理和一個被分配到每個測試環境的測試員。role記錄類型包括的字段要確定“角色”名，該角色所應用到的應用程序，一個簡要描述信息和一個被分配到應用程序角色上的用戶的參照列表。用戶可能被分配到一個應用程序中的多個角色，并且一個用戶也可以被分配到相同或不同角色的多個應用程序。
　　
　　application記錄用于確定應用程序名，與應用程序相關聯的環境，此應用程序的批準人和可以被執行以完成源代碼構造或編譯和代碼遷移的（多個）命令。可以是多個命令的原因是由于代碼可能需要使用調試參數進行重新構造，或者可能需要在遷移之前進行卸載，執行安裝或簡單地更新一些文件。不同的應用程序有不同的安裝、配置和卸載需求，因此就需要有多個腳本的能力。application記錄要求確定ClearCase UCM項目。當一個部署被完成時，執行部署的人員要選擇一個必須與application中確定的UCM_Project相關聯的ClearCase基線。application記錄需要在“Approvals_for_I”、“Approvals_for_Q”和“Approvals_for_P”字段中確定角色。這些字段是參照列表，因此批準過程可以要求多個角色。deployment記錄的實際批準過程將會在本文中后面進一步具體描述。
　　
　　Application記錄也包括定義Issue和ChangeRequest記錄參照的字段。這些關聯用來確定一個特定的Issue或ChangeRequest被關聯到哪一個application。對于小的ClearQuest部署－－每個項目或應用程序有其自己的數據庫，這不是真正必需的。然而，如下一段落所討論的，為了達到集成和報告的目的，時常會在一個單獨的數據庫中包括多個項目。
　　
　　此顧客的初始ClearQuest構架是要對每個項目有一個ClearQuest用戶數據庫。在產品環境中，多個項目會集合在一起形成可交付產品。此構架對每個團隊都運行得非常好，因為問題和變更請求被隔離起來并且輕易進行治理。然而，這種實施對于不同的系統測試團隊進行得不太好。假如一個測試團隊的成員在測試中發現一個問題，測試團隊成員將必須判定出此變更請求應當歸于哪個項目，然后到特定的ClearQuest用戶數據庫去，并且假如測試團隊成員在錯誤的數據庫中輸入了變更請求，那么一旦找到了正確的數據庫，就要必須手動將數據復制到正確的ClearQuest用戶數據庫中。最后的抱怨是測試人員不能跨多個不同的ClearQuest用戶數據庫創建報告來確定哪些變更請求已經被完成了，而這樣可以使測試團隊執行回歸測試。要下決心開始計劃將不同的ClearQuest用戶數據庫遷移到一個更大的數據庫，這樣可以滿足測試團隊利益相關者的需要。在計劃此遷移中，application字段被用在Change Request和Issue記錄類型上。
　　
　　創建Deploy_Cmd記錄類型來存儲部署過程中使用的不同命令。這被定義成一個分開的記錄類型（與之相反的是簡單地使

上一篇：用 One-JAR 簡化應用程序交付

下一篇：Java對Domino Objects的訪問控制