在 IBM Bluemix 云平臺上開發(fā)并部署您的下一個應(yīng)用。

開始您的試用

簡介

一般來說,，在敏捷開發(fā)模式下,，整個開發(fā)周期被分割成多個短期的迭代（典型的為二到十二個星期）。在每個迭代的開始,，開發(fā)團隊與客戶共同決定本迭代所要實現(xiàn)的需求,?？赡苊總€迭代周期開始時都有很多需求,，不能在一個迭代里面實現(xiàn)，所以需要按一定的優(yōu)先級順序來決定先實現(xiàn)哪些需求,。在一次迭代中沒有被實現(xiàn)的需求被保留下來,，作為一個需求庫，在下一個迭代開始的時候開發(fā)團隊和客戶會再次選擇高優(yōu)先級的需求,。迭代如此循環(huán),。如圖 1 所示。

圖 1. 敏捷開發(fā)模式示意圖

敏捷開發(fā)模式具有兩個非常重要的特點,。一個是每個迭代結(jié)束應(yīng)該有一個可展示的“產(chǎn)品”（可能這個產(chǎn)品并不完善）提供給客戶,，客戶基于當前的“產(chǎn)品”提出新的需求或者變更。這些新需求和變更和上個迭代留下的需求一起進入下個迭代,。另外一個特點是在每個迭代期間,，開發(fā)人員只致力于當前迭代的需求。這樣做的意圖是,，保持設(shè)計的簡單,，并且防止不必要的特性膨脹。代碼還是不斷地集成的,，并頻繁地以很小的單位進行實現(xiàn),、測試及提交，這可以利用在提交時刻調(diào)用的自動化構(gòu)建過程來檢查集成錯誤,。

想要實現(xiàn)上述這些最佳實踐,，一個輕量級、快速響應(yīng),、功能全面簡潔并且兼容性強的軟件構(gòu)建和版本管理工具必不可少,。

而 CCRC 7.1 就是一個滿足上述需求的軟件構(gòu)建和版本管理工具,。下面首先介紹 CCRC 7.1 具有哪些新功能，然后介紹如何基于 CCRC 7.1 實現(xiàn)高效的敏捷開發(fā),。

回頁首

CCRC 7.1 中面向敏捷開發(fā)的新功能

顧名思義,，ClearCase Remote Client 是 ClearCase 的一個遠程客戶端。在版本控制方面,，它延用了 ClearCase 的整套概念,，基本工作流程也是基于 ClearCase。關(guān)于這些基本信息,，請參照 CCRC 7.0 及之前的版本或者 ClearCase 相關(guān)文檔,，這里不再贅述。作為一個遠程客戶端,，CCRC 有如下優(yōu)點,。

• 支持廣域網(wǎng)。無論 CCRC 客戶端是否在 ClearCase 服務(wù)器所在的局域網(wǎng)內(nèi),，只要具有相應(yīng)權(quán)限,，CCRC 都可以鏈接到 ClearCase 服務(wù)器。
• 輕量級,。相對其它胖客戶端 CCRC 需求的資源非常少,。
• 與開發(fā)環(huán)境集成。CCRC 作為 Eclipse 的插件存在的,，與 Eclipse 無縫連接,。開發(fā)環(huán)境與版本控制完全融合。

為了適應(yīng)敏捷開發(fā),，CCRC 7.1 版本增加了許多新功能,。下面對這些新功能進行簡單介紹。

簡潔導航器視圖

在 CCRC 7.1 中,，所有 ClearCase 相關(guān)的資源都通過一個導航器視圖以層次化格式顯示,。用戶可以非常簡單快捷的修改其中的任何內(nèi)容。圖 2 更直觀的表示了這種顯示方式的效果,。

圖 2. CCRC 7.1 中的 ClearCase 導航器視圖

從圖中可以看到,，ClearCase 導航器視圖下主要有兩項，一項是本地視圖,，列出所有的本地靜態(tài)視圖,。另外一項是服務(wù)器信息，該項信息下面顯示相應(yīng)服務(wù)器上的 ClearCase 和 ClearQuest 信息,。ClearCase 下面顯示了 ClearCase 服務(wù)器上的組件 VOB 及其屬性以及項目 VOB 及其屬性,。ClearQuest 下面顯示了 ClearCase 服務(wù)器上 ClearQuest 的連接信息。

暫掛更改視圖

一般來說,，一個開發(fā)團隊里有多個開發(fā)人員,。在一開始他們是獨立工作的,，當開發(fā)工作進行了一個階段之后（比如一天），他們要集成每個人的開發(fā)工作作為統(tǒng)一代碼資源,，然后每個開發(fā)人員把統(tǒng)一的代碼資源引入到自己的工作空間,。如圖 3 所示

圖 3. 開發(fā)階段—集成和同步

這里涉及到兩個階段，面臨一個問題,。兩個階段分別是交付和同步,，面臨的問題是沖突。交付是指將各個開發(fā)人員的工作集合起來,，生成統(tǒng)一代碼資源,，這里可能會碰到不同的開發(fā)人員的內(nèi)容沖突。同步是指開發(fā)人員將統(tǒng)一代碼資源整合到自己的獨立工作空間,，這里也可能會碰到內(nèi)容沖突的問題,。

很多的版本控制管理軟件處理沖突的方法就是先軟件自動整合，然后如果需要就請求人工干預(yù),。但是在軟件自動整合之前,，用戶并不能看到即將整合的內(nèi)容到底是什么。如果內(nèi)容不是用戶想要的,，或者內(nèi)容存在問題,，在軟件自動整合之后,，就只能選擇回滾操作,。這種方式很可能浪費時間。

CCRC 7.1 提供了一個查看變更的暫掛更改視圖,，所謂“暫掛”,，就是待解決。相對于本地工作空間來說,，暫掛更改有三種類型,，輸入變更表示只有其它工作空間對文件做了修改，輸出變更表示只有本地工作空間對文件做了修改,，沖突變更表示本地和其它工作空間都對文件做了修改,，并且有沖突的地方。暫掛更改視圖就是要根據(jù)一定的規(guī)則將這些變更顯示出來,。

我們知道,，ClearCase 支持兩種工作模式，一直 Base ClearCase,，只需要 ClearCase 進行版本管理,。這種模式下文件的變更不與活動相關(guān)。所以在這種模式下暫掛更改視圖是按照組件來分組顯示的,。如圖 4 所示,。

圖 4. 暫掛更改視圖—按文件夾分組

ClearCase 的另外一種工作模式是 UCM,，這種模式下文件的變更與活動相關(guān)聯(lián)。所以這種模式下暫掛更改視圖是按照活動來分組顯示的,。如圖 5 所示,。

圖 5. 暫掛更改視圖—按活動分組

在暫掛更改視圖中，上下文菜單非常豐富,。其中常用的有兩種,，一種是預(yù)覽變更，另外一種是解決變更,。使用非常方便,。

暫掛更改視圖從顯示上就體現(xiàn)了它的簡潔性，不同的工作模式采取不同的顯示方式,，另外,，工具欄還提供是否顯示某種變更的工具（比如只顯示沖突變更，或者只顯示輸入變更等）,。更重要的是,，豐富的上下文菜單是的用戶處理變更方便快捷。

高級交付 / 同步選項

在敏捷開發(fā)過程中交付和同步是比較頻繁的動作,，所以需要有方便快捷的方式,。CCRC 7.1 除了提供默認的交付 / 同步操作之外，還提供了高級交付 / 同步選項,。由于 Base ClearCase 不支持視圖下的交付 / 同步操作,，所以這里所說的交付 / 同步操作都是針對 UCM 視圖的。針對 Base ClearCase 模式,，可以使用暫掛更改視圖或者 ClearCase 合并查找工具完成交付 / 同步功能,。

首先介紹高級交付選項。在導航圖內(nèi)選擇一個需要交付的視圖,，打開右鍵菜單,，選擇 Deliver->Advanced。彈出對話框如圖 6 所示,。

圖 6. 高級交付

這個對話框主要分兩部分,，一部分是交付目標流和視圖信息，可在交付前進行修改,。另外一部分是需要繼承的活動以及當前被檢出或者 Hijack 的文件,。可以選擇交付哪些活動,。另外對被檢出或者 Hijack 的文件,，可以選擇檢入或者回滾。如果保持檢出或 Hijacked 狀態(tài)，交付前會提示說有處在檢出或 Hijacked 狀態(tài)的文件,，它們將不會被交付,，用戶可以選擇繼續(xù)也可以選擇放棄。

其次介紹高級同步選項,。打開方式與高級交付非常相似,，即在視圖右鍵菜單里選擇 Rebase -> Advanced. 彈出對話框如圖 7 所示。

圖 7. 高級同步

如圖所示,，這個對話框也是有兩個部分,，上面是同步流、視圖信息,。下面供用戶選擇集成流的基線,。有很多種選擇，用戶可根據(jù)自己的習慣來使用,。另外,，如果當前視圖下存在檢出或 Hijacked 狀態(tài)的文件或文件夾，會被列出來,。至于此時是不是可以同步,，則要看項目策略的設(shè)置。各個團隊有自己的偏好,。

豐富的“編輯配置”視圖

使用編輯配置視圖用戶可以轉(zhuǎn)入或卸載資源,。在 CCRC7.0 及其之前的版本中，用戶每次只能裝入一個 VOB,。如果想裝入多個 VOB,，唯一的辦法就是多次重復(fù)操作。而在 CCRC7.1 的編輯配置視圖下,，用戶可一次性裝入多個 VOB,。另外，該視圖還提供 VOB 過濾功能,。比如只顯示公用 VOB 或私有 VOB，這對具有多個 VOB 的用戶來時是非常有用的,。

另外,，也可通過編輯配置視圖來編輯版本選擇規(guī)則。在 CCRC7.0 及其之前的版本中,，用戶需要手動輸入所有的版本選擇規(guī)則,，無法重用已有視圖的版本選擇規(guī)則。而 CCRC7.1 提供了這個功能,，更方便了用戶的使用,。

與 ClearQuest 集成

UCM 是 IBM Rational 的一個非常成熟的統(tǒng)一變更管理解決方案。CCRC 7.1 自然是支持這一解決方案的。但是其實如果用戶不能在客戶端直接查看存放在 ClearQuest 里面的活動,，而需要轉(zhuǎn)到 ClearQuest 的某個客戶端去的話是非常不方便的,。CCRC 7.1 的集成了 ClearQuest，使得用戶可以直接在 CCRC 里面查看活動,，另外在進行檢入檢出等操作的時候可以隨時創(chuàng)建活動,。這個功能使得用戶無需做任何界面切換，非常方便,。

回頁首

基于 CCRC 7.1 的敏捷開發(fā)模式

從圖 1 我們看到敏捷開發(fā)模式具有兩個重要特點,。即在開發(fā)期間的可展示“產(chǎn)品”以及不斷變化的需求。而這兩個特點都強調(diào)一個屬性,，那就是敏捷,。在對于敏捷模式的支持上，CCRC 7.0 及之前版本和 CCRC 7.1 略有不同,。本節(jié)將首先比較 CCRC 7.1 與 CCRC 7.0 及之前的版本下的敏捷開發(fā)模式,，然后介紹基于 CCRC 7.1 的敏捷開發(fā)模式的工作流程。

兩種開發(fā)模式比較

在基于 CCRC 7.0 及之前版本的開發(fā)模式下,，每個開發(fā)人員在私人流 / 分支（流是 UCM 模式下的概念,，分支是 Base ClearCase 下的概念），完全通過與集成流 / 分支的交付和同步操作來取得與其他開發(fā)人員的聯(lián)系,。如圖 8 所示,。

圖 8. 基于 CCRC7.0 及之前版本的敏捷開發(fā)模式

由于 CCRC 7.0 及之前版本并不提供暫掛視圖之類的簡便的變更解決功能，所以在圖 8 的模式下開發(fā)人員之間的溝通變得比較困難,，而敏捷開發(fā)模式最強調(diào)的一點就是溝通快捷順暢,。

基于 CCRC 7.1 的開發(fā)模式在之前的開發(fā)模式上做了改進。如圖 9 所示,。

圖 9. 基于 CCRC 7.1 的敏捷開發(fā)模式

圖 9 所示的開發(fā)模式與圖 8 所示的開發(fā)模式最大的不同在于,，新的模式下開發(fā)人員是在共享流 / 分支上工作，而舊的模式下開發(fā)人員是在私人流 / 分支上工作,。在這種模式下,，再加上 CCRC 7.1 的新功能，敏捷開發(fā)將會進行的非常順暢,。下面本文將會通過該模式的工作流更進一步說明 CCRC 7.1 對敏捷開發(fā)的支持,。

基于 CCRC 7.1 的敏捷開發(fā)工作流程

通過圖 3 可以看到，敏捷開發(fā)的基本流程就是工作人員在開發(fā)流 / 分支上工作,，然后把工作內(nèi)容交付到集成流 / 分支上,。另外重新開始新一輪開發(fā)之前需要從集成流 / 分支上同步開發(fā)流 / 分支。為了把這個工作流程更清晰的與 CC 中流 / 分支的概念聯(lián)系起來,，圖 10 以流 / 分支為參照物展示了敏捷開發(fā)的基本流程,。

圖 10. 敏捷開發(fā)流 / 分支結(jié)構(gòu)圖

注：圓圈里面的數(shù)字表示版本號。

豎虛線表示有多個未顯示版本號

橫虛線表示有多個未顯示共享開發(fā)流 / 分支

很顯然，開發(fā)人員開始工作的時候需要這個結(jié)構(gòu)已經(jīng)存在或者可以自動生成,，那么誰來完成那些初始化的工作呢,？在共享開發(fā)流 / 分支上工作時，誰來負責做交付和同步的工作呢,？什么時間做這些工作呢,？集成流 / 分支上的統(tǒng)一代碼資源有什么人維護呢？如果能回答這一系列問題,，基于 CCRC 7.1 的敏捷開發(fā)工作流程就顯而易見了,。

為了方便起見，本文假設(shè)某個開發(fā)團隊有如表 1 所示的角色分配,。當然,，每個團隊都有自己的情況，這里只是給出一個比較常見的分配方式,。

表 1. 團隊角色分配

這里，小組長及其組員在開發(fā)中是在一個共享流 / 分支上工作的,。

經(jīng)過角色分配,，基于 CCRC 7.1 的敏捷開發(fā)工作流程就呼之欲出了。圖 11 以簡潔的方式描述了這個流程,。

圖 11. 基于 CCRC 7.1 的敏捷開發(fā)工作流程

這個似乎看起來非常簡潔,。那么每個步驟里面都需要做哪些工作呢？CCRC 7.1 又是怎樣通過它的新功能使得這些工作變得非?？旖莘奖隳?？下面將逐步介紹每個步驟的細節(jié)。

初始化,、配置環(huán)境：這個步驟包括搭建 ClearCase 相關(guān)的服務(wù)器,，創(chuàng)建 VOB，項目等,。具體請參考 Rational ClearCase7.1 Infocenter（參見參考資料）,。本步驟結(jié)束后，已有代碼資源應(yīng)該具有主流 / 分支版本,。

創(chuàng)建開發(fā)流 / 分支,、創(chuàng)建開發(fā)視圖：這兩個步驟合起來的目的就是要創(chuàng)建開發(fā)工作空間。其實在創(chuàng)建開發(fā)視圖的時候可以自動創(chuàng)建開發(fā)流 / 分支,。之所以把這兩個步驟分開，是考慮到開發(fā)環(huán)境中可能有多個 VOB,，并且有一個管理 VOB,，所有的流 / 分支等元數(shù)據(jù)都存放這個管理 VOB 內(nèi)。這種情況應(yīng)該獨立創(chuàng)建開發(fā)流 / 分支。在 CCRC 7.1 的導航圖中選擇 VOB 所在的服務(wù)器 -> Component VOBs -> 某個 VOB -> Branch Types,。打開 Branch Types 郵件菜單,，選擇創(chuàng)建流 / 分支，在彈出對話框中填寫相應(yīng)內(nèi)容即可,。

加入某個項目時默認會創(chuàng)建一個新開發(fā)流,，如圖 12 所示。

圖 12. 創(chuàng)建 / 重用開發(fā)流

如果想創(chuàng)建新流,，直接填寫 Stream name 即可（注意,，流名必須唯一）。若想重新已有流,，點擊按鈕 Stream Options,，在彈出對話框 Stream Options 里面選擇 Re-use an existing development stream，然后在下拉框中選擇一個已有流即可,。

在創(chuàng)建 Base ClearCase 視圖時,，會自動生成默認版本選擇規(guī)則。如果想修改規(guī)則,，在視圖右鍵菜單里選擇 ClearCase View Configuration,，在被打開的試圖里選擇 Load Rules 頁，選擇編輯工具,，打開 Edit Configuration 對話框,，選擇 Version Selection Rules，編輯規(guī)則即可,。

可以看出,，在創(chuàng)建工作空間方面，CCRC 7.1 即考慮了多種情況,，也為各種情況提供了統(tǒng)一方便的界面,。

開發(fā)：開發(fā)人員進行開發(fā)工作。由于多個開發(fā)人員共享一個開發(fā)流 / 分支,，所以在開發(fā)過程中應(yīng)該會頻繁的用到暫掛更改視圖以查看所在開發(fā)流 / 分支上的最新變化,。這使得開發(fā)人員隨時跟進當前開發(fā)狀態(tài)。

交付：經(jīng)過一段時間的開發(fā)工作之后,，小組長應(yīng)該將本開發(fā)流 / 分支上的內(nèi)容交付到集成流 / 分支上,。在 UCM 模式下，可使用默認的或者高級交付 / 同步選項,，也可以在暫掛更改視圖里進行交付操作,。在 Base ClearCase 下，可在暫掛更改視圖里進行交付操作,。

維護交付流 / 分支：各小組將工作內(nèi)容交付到集成流 / 分支之后,，團隊領(lǐng)導需要維護集成流 / 分支上的統(tǒng)一代碼資源,。其中應(yīng)該包括解決沖突、兼容性等常見問題,。另外維護中有一個非常重要的問題,，那就是頻繁的集成構(gòu)建會使得每次集成的問題不斷積累，最壞的情況可能導致整個代碼資源癱瘓,。這個問題是敏捷開發(fā)團隊經(jīng)常遇到的大難題,。持續(xù)集成從一定程度上解決了這個問題。本文下一節(jié)將介紹基于 CCRC 7.1 的持續(xù)集成,。

如果某次集成的結(jié)果很好,，小組領(lǐng)導可能會制作并推薦一個基線供各小組同步。在 CCRC 7.1 里,，制作和推薦基線都非常簡單,。在導航圖內(nèi)的服務(wù)器信息下面找到需要制作或推薦基線的集成流 / 分支，選擇右鍵菜單里的創(chuàng)建基線,、推薦基線,，在彈出對話框中填寫相應(yīng)信息即可。

同步：通過持續(xù)集成,，前期代碼得到基本驗證,，下一輪的開發(fā)工作開始。在開始之前各開發(fā)小組應(yīng)該同步本開發(fā)流 / 分支的代碼,。在 UCM 模式下,，可使用默認的或者高級交付 / 同步選項，也可以在暫掛更改視圖里進行同步操作,。在 Base ClearCase 下,，可在暫掛更改視圖里進行同步操作。

至此,，本文介紹了基于 CCRC 7.1 的敏捷開發(fā)流程,。之前提到敏捷開發(fā)的一個重要的最佳實踐，持續(xù)集成,，下面介紹基于 CCRC 7.1 的持續(xù)集成,。

回頁首

基于 CCRC 7.1 的持續(xù)集成

通過敏捷開發(fā)流程里，集成非常頻繁,。團隊領(lǐng)導需要花很多時間來維護集成流 / 分支上的統(tǒng)一代碼,。而且集成構(gòu)建非常的繁瑣，也會消耗很多時間和精力,。持續(xù)集成（Continuous Integration）從一定程度上解決了這個問題,。下面首先介紹什么是持續(xù)集成。然后介紹基于 CCRC 7.1 的持續(xù)集成的實現(xiàn),。

持續(xù)集成

持續(xù)集成是敏捷開發(fā)的一個最佳實踐,。它是通過一個自動化的過程來達到自動集成構(gòu)建和基礎(chǔ)測試的目的,。Martin Fowler 在他的文章“Continuous Integration”這樣定義持續(xù)集成：Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day,。

我們認為持續(xù)集成是一個軟件開發(fā)最佳實踐,，其中集成、構(gòu)建和基礎(chǔ)測試依次重復(fù)進行,。從過程的角度來說,，持續(xù)集成是一個循環(huán)的過程，每個循環(huán)包含三個部分：更新集成工作空間,、集成構(gòu)建和反饋,。圖 13 顯示了三個步驟的關(guān)系。

圖 13. 持續(xù)基本集成結(jié)構(gòu)圖

第一步,，版本控制,，由版本管理軟件完成，比如 ClearCase 7.1,。第二步,，集成構(gòu)建。第三步,，反饋,，可以通過網(wǎng)頁或者郵件形式。其中最為關(guān)鍵的就是第二步集成構(gòu)建?，F(xiàn)在已經(jīng)有很多軟件實現(xiàn)了持續(xù)集成這個最佳實踐,，比如 Rational BuildForge。

實現(xiàn)持續(xù)集成

前面介紹了持續(xù)集成的基本概念了結(jié)構(gòu),，本小節(jié)將實現(xiàn)基于 CCRC 7.1 的持續(xù)集成,。

首先來分析需要哪些工具。通過圖 13 可以看出,，最基本的工具有三個,，第一，版本控制工具,，這里我們使用 ClearCase 7.1,，客戶端則使用 CCRC 7.1。第二,，集成構(gòu)建工具,，可使用 IBM Rational BuildForge。第三,，反饋工具,，為了簡便起見，本文直接使用網(wǎng)頁反饋,。在實際使用中,，可使用郵件反饋,，比如 IBM Lotus Notes。確定了工具后,，把它們帶入到結(jié)構(gòu)里,，不難得到基于 CCRC 7.1 的持續(xù)集成的架構(gòu)圖。如圖 14 所示,。

圖 14. 基于 CCRC 7.1 的持續(xù)集成的架構(gòu)圖

根據(jù)上面的架構(gòu)圖,，很容易得出基于 CCRC 7.1 的持續(xù)集成需要做下面的工作：

• 初始化環(huán)境,，因為前面介紹了基于 CCRC 7.1 的敏捷開發(fā)工作流程,，我們假設(shè) ClearCase 7.1 服務(wù)器以及 CCRC 7.1 客戶都已經(jīng)搭建好了,。這里只需要搭建持續(xù)構(gòu)建服務(wù)器,?？梢允褂?IBM Rational BuildForge 等工具,，這里不再贅述,。
• 環(huán)境配置,，配置持續(xù)構(gòu)建服務(wù)器,，開發(fā)環(huán)境等,。
• 編寫代碼更新程序，在持續(xù)集成之前,，需要獲得最新的集成代碼,。ClearCase 7.1 提供了 API 供用戶調(diào)用，可通過程序?qū)崿F(xiàn)自動更新代碼,。

下面主要介紹最后的步驟,，即如何基于 CM API 編寫代碼更新程序。

ClearCase 7.1 提供了 CM API,，用戶可以基于這些 API 來編寫一個用戶在客戶端更新代碼的程序,。那么，在編寫這個程序之前,，需要回答下列問題：

• CM API 具有怎樣的架構(gòu),？
• CM API 在什么位置？
• 基于 CM API 的代碼更新程序的流程是怎樣的,？

下面依次回答這些問題,。

代碼更新程序的作用就是從客戶端發(fā)送代碼更新的請求給服務(wù)器，然后服務(wù)器做出響應(yīng),，最后代碼得到更新,。根據(jù)這個角度，圖 15 給出了 CM API 的結(jié)構(gòu)圖,。

圖 15. CM API 的結(jié)構(gòu)圖

可以看出,，CM API 就是通過一層層的 Provider 來處理客戶端的更新請求的。

CM API 在 ClearCase 的安裝路徑下,，總共包含 5 個 JAR 文件,。如圖 16 所示,。

圖 16. CM API 的位置

第一和第二個問題都得到了解決，下面解決第三個問題,。

程序的最終目的是要更新代碼,，在更新之前需要知道更新目標。而所有的更新目標都在靜態(tài)視圖內(nèi),，所以要想得到更新目標,，要先得到靜態(tài)視圖。通過 CM API 架構(gòu)圖可以知道,，要想得到任何對象，必須先創(chuàng)建相應(yīng)的 Provider,。那么,，很顯然，程序的流程如下：

• 創(chuàng)建 Provider,，示例代碼如清單 1,。

清單 1. 創(chuàng)建 Provider

//new an instance of class MyAuthCallback
Callback callback = new MyAuthCallback(serverUrl, login, password);
//get provider with instance of callback
CcProvider provider = (CcProvider)
 Providerfactory.createProvider(CcProvider, .PROVIDER_CLASS, callback);

• 獲得靜態(tài)視圖，示例代碼如清單 2,。

清單 2. 獲得靜態(tài)視圖

//new object of file with the root directory.
File file = new File(loc);
//the directory is a copy area for a certain snapshot view.
StpLocation stplocation = (StpLocation)
 provider.filePathLocation(StpLocation.Domain.CLEAR_CASE, file);

• 獲得視圖內(nèi)元素,，示例代碼如清單 3。

清單 3. 獲得視圖內(nèi)元素

//get proxy for resource
ControllableResource res = getProxy(loc, provider);
//get properties for resource.
PropertyRequest prop = new PropertyRequest
(new PropertyRequestItem[] (ControllableResource.IS_VERSION_CONTROLLED));
Res = (ControllableResource) res.doReadProperties(prop);
//if the resource is under source control, add it into resource list. It will be updated
if ( res.getIsVersionControlled()) resourcelist.add(res);

• 更新目標,，示例代碼如清單 4,。

清單 4. 更新目標

//update resource
View.doUpdate(resourcelist, PropertyRequest.EMPTY);

回頁首

總結(jié)

Rational ClearCase Remote Client (CCRC) 7.1 是 ClearCase 7.1 的輕量級客戶端，它具有諸多優(yōu)點,，如簡潔導航器視圖,、暫掛更改視圖、集合操作,、高級交付 / 同步選項以及與 ClearQuest 集成,。所有這些優(yōu)點都使得 CCRC 7.1 非常適合現(xiàn)在流行的敏捷開發(fā)模式。本文介紹了基于 CCRC 7.1 的敏捷開發(fā)模式工作流程,。并提出了基于 CCRC 7.1 的持續(xù)集成的實現(xiàn)方法,。