IBM RTC 是一個軟件協作交付環境，它包含了計划制定及管理，工作項集成管理，代碼版本控制管理，以及構建管理等諸多功能，這些功能使得Jazz環境的協作能力非常強大。在RTC中，用戶可以通過工作項對工作內容進行信息更新和任務分配，借助工作項和人員之間的聯系方便地進行信息的交流和展示，並可以從不同的層面和角度了解整個Team的工作進行情況。
這份文檔描述了RTC應用於軟件開發活動的通用模式，並介紹了推薦的流程以及使用RTC進行日常開發活動的策略。希望通過本文向軟件開發團隊介紹一種可靠的流程和工具環境，來支持項目的軟件開發需求。在軟件開發活動中應用RTC能夠使得管理和平衡項目成員工作變得更為簡單和清晰，並且可以在項目組內部進行有效的溝通，提高生產合作效率。
內容安排
本文內容的結構如下：在第一章將介紹RTC中的相關定義，讓用戶熟悉RTC使用中的一些常用概念。在第二章中將介紹軟件開發團隊在開始使用RTC時，如何對RTC項目進行基礎設置以適應團隊需求。第三章將介紹RTC應用於具體軟件開發活動時的使用方式，重點介紹如何使用RTC進行項目管理和代碼管理/版本控制。最后是對本篇文章的總結。
1. 定義：
RTC：Rational Team Concert
SCM：Source Code Management源代碼管理
Local Workspace： 本地工作空間，它是一個與存儲空間關聯的客戶文件系統，用戶可以在這個系統中處理component的工作。這個工作空間可以獨立地在本地存在，也可以連上服務器，進行更新的上傳或者下載。
Repository Workspace： 服務器端的個人存儲空間，它可以視作Stream的一個鏡像，並可以與本地工作空間相關聯，處理來自於本地工作空間的變更或者接受來自於Stream的變更。
Stream：類似於branch，或者release，是一個存儲對象，它包含一個或多個component，並且與另外的Stream版本獨立。Stream會追蹤版本變化的歷史記錄。
Component： Component 是一個組件的集合，例如一個Eclipse的插件，或者一組描述網頁設計的文檔。 Component的owner是project area，而且只有project area的成員才能夠訪問具備版本控制的component中的代碼。
Compartment：基本的控制列表。在RTC中，對應Project Area。應控制使最少人數的成員可以訪問compartment，並且有准入業務流程控制。
Change Set： 變更集，一個存儲對象，是某次開發活動后發生變更的文件集合，通常與一個工作項相關聯。
Pending Changes：待處理的變更。當local workspace，repository workspace和stream之間由於發生變更導致出現不一致的情況時，需要用戶決定處理方式的情況。這些待處理的變更將會被列在pending changes視圖中，等待用戶的操作決定，例如接受，交付，或者是處理沖突。
Baseline：基線，記錄某個特定時間點的單個component內的配置項狀況。
Snapshot：快照，記錄某個特定時間點的多個component內的配置情況，可以覆蓋一個或者多個stream。
Checkin：這個操作可以將變更集由本地工作空間上傳至服務器端的個人工作空間
Accept: 這個操作可以將服務器端的變更集和baseline接收到個人工作空間
Deliver：這個操作可以將變更交付至stream
Load： 這個操作可以將變更集從Stream或者其它工作空間下載至本地工作空間
Build Definition：構建定義，可以定義build的時間間隔，哪些build腳本被調用，以及build從哪些工作空間中取得文件。
WorkItem：用於描述工作的細節和狀態，有多種類型和層次，例如從最大的類型到小的類型有Epic，Story，Task以及Defect， Blocker等其他類型，並且可以由用戶自定義新的WorkItem類型。
RTC項目的基礎設置
當軟件開發團隊開始使用一個剛創建的RTC項目來支持軟件開發活動時，需要對該RTC項目作一些基礎設置，以使RTC項目適應團隊需要，下面就對這些基礎設置作簡要的說明：
2.1 角色設置 (Role Configuration)
角色定義了一個團隊中成員的不同職責，並決定了團隊成員在RTC項目區域中所具有的的權限。
每個項目區域(Project Area)和每個團隊區域(Team Area)都有角色的設置。這兩層的角色權限設置是相互獨立的。可以通過兩層的角色權限設置實現復雜的權限控制。
以Scrum模板為例，該模板提供了如下幾種預定義的角色，項目管理員可以根據需要添加自定義的角色。
▲圖1.RTC的角色設置
2.2 項目設置 (Project Configuration)
通過對項目權限的設置，使得不同角色擁有不同水平的權限，規定了角色可以做和禁止的操作，對角色功能做了很好的區分
▲ 圖2.RTC的項目權限設置(角色權限矩陣圖)
2.3 團隊設置 (Team Configuration)
在團隊區域內部可以對角色權限作更進一步的設置，其設置方法和項目設置類似，也是針對不同角色賦予操作權限。
▲ 圖3.RTC的團隊權限設置(角色權限矩陣圖)
2.4 訪問控制 (Access Control)
出於對項目安全方面的考慮，RTC項目提供了對項目的訪問控制，可以限制僅有本項目成員可以訪問項目區域，或者設定訪問名單，允許訪問名單中的人員訪問項目。
▲圖4.RTC的訪問控制
2.5 前置條件設置 (Preconditions Configuration)
在項目中，可以對某些操作的前置條件(Preconditions)或者跟進操作(Follow-up actions)進行設置：
例如，我們可以設置所有人在執行Deliver操作之前，必須要有相關的工作項和注釋。這樣可以使每次的Deliver都有確切的根據和記錄。
▲圖5.RTC的操作前置條件設置
2.6 時間線設置 (Timeline Configuration)
可以通過時間線設置明確團隊的開發進度，規划開發周期。
▲ 圖6.RTC項目的時間線設置
2.7 工作項分類設置 (Work Item Categories Configuration)
可以在Project的Work Item Categories標簽中進行Categories的設置，工作項分類是樹形結構的，用戶可以自己定義這個樹形結構的每個分支和節點。在創建工作項時，用戶就可以在File Against屬性中選擇已設置的分類
▲圖7.RTC的工作項分類設置
小結：
RTC項目的基礎設置到這里告一段落，完成這些基礎設置之后，團隊就可以開始借助RTC開始工作了。事實上，RTC還支持工作項和流程定制的功能，但是限於篇幅，本文不對這方面作深入探討。
3. 在軟件開發活動中使用RTC
3.1 使用RTC進行項目管理
RTC具有計划制定和管理以及強大的工作項管理的功能，可以很好的實現項目管理支持。下面介紹RTC在項目管理方面的應用。
3.1.1 用Product Backlog管理產品需求
RTC的Product Backlog是一種特殊類型的Plan，可以將它視作一個需求池，它在產品開發的初期生成，以列表形式描述用戶的需求，作為產品的待辦事項，並在開發過程中不斷更新完善。由Product owner負責管理。
▲ 圖8.一個Product Backlog的示例
3.1.2 制定項目計划
項目經理可以根據時間線划分，制定Release Level和Iteration Level的開發計划。開發計划可以明確該階段的工作目標。可以從Backlog中將需求拖拽到Plan中，作為這一階段的開發目標。項目成員可以方便的在Plan視圖下查看該階段的工作項狀態。
▲ 圖9.RTC提供的Sample項目中的Plan視圖
3.1.3 利用工作項管理開發任務
工作項用來描述某一項具體任務，根據粒度的不同，可以划分為Epic，Story，Task這些不同層級的工作項。Epic是位於頂層的工作項，它描述某個大的方面的工作。Story則描述一個具體的事務性的可追蹤工作，Task則細化到daily的工作任務，可以直接由完成與否來衡量。工作項的owner確保工作項的執行，可以添加工作項的subscriber，使得工作項有任何的狀態更新都會通知subscriber列表中的項目成員。各個工作項可以建立聯系，例如父子關系，驗證關系等等，通過這些關聯關系，我們能從整體上把握目前的工作狀態以及工作之間的依賴關系，從而更好地發現對工作進度造成影響的問題並有效解決問題。
▲圖10.RTC中不同level的工作項
項目成員可以方便的通過建立查詢，通過各種條件組合查找到符合條件的工作項。這些查詢可以保存在查詢預定義列表中以備隨時使用。
▲圖11.通過建立查詢查找符合條件的工作項
3.2 使用RTC進行源代碼管理和版本控制
RTC另一項強大的功能就是支持源代碼管理和版本控制，可以支持多人團隊共同開發，能夠確保更新被所有開發成員及時得知，並且可以預先偵測到潛在的代碼沖突。
我們從以下幾個方面來介紹RTC的代碼管理和版本控制功能。首先當我們要使用RTC管理Source Code時候，應明確如何將Source Code划分為不同的Component存放，並根據具體的開發，測試，構建需求划分Stream。在開發人員進行開發活動，並將自己的對當前代碼的變更上傳至服務器時，需要理解RTC進行代碼變更的工作模式並正確操作。3.2.2節介紹了RTC代碼管理的三重工作空間模式，3.2.3節則介紹了如何理解視圖中變更集的標記意義並執行相應的操作。在這一小節最后將介紹RTC強大的代碼歷史記錄功能：基線和快照，可以方便地對代碼歷史進行追溯和恢復。
3.2.1 Stream 和 Component划分的策略
Stream可以視作某個版本的代碼集合，一般情況下，我們要為當前release建立一個主開發Stream。我們可以借助RTC的快照和Flow Target功能方便的復制一個stream的當前狀態成為另一個Stream，使其成為主開發team的一個分支。出於對構建(Build)的需求，我們還可以建立一個集成stream，用來將開發stream中的內容作一些整合，用來進行構建。
Component是某一個功能模塊的代碼集合，可以根據功能模塊對代碼進行component划分。例如名為Install的Component包含了安裝模塊，名為Interface的component包含了界面設計模塊等等。來自第三方的open source code以及核心的Jewel Code應該分別單獨用Component存放，以確保代碼來源清晰並且受到保護。可以為Component指定Owner(Owner可以是個人，團隊或者整個項目區域)，嚴格控制Component內容的讀寫權限。
當代碼按我們划分好的stream和component存放於RTC的工作空間時，我們就可以在RTC的代碼管理和版本控制功能支持下進行協作式的代碼開發活動了。下面將介紹RTC代碼管理的三重工作空間模式。
3.2.2 三重工作空間的工作模式
RTC的代碼存在於三重相互關聯的工作空間，如圖所示：
▲圖12.RTC的三重工作空間(Source Code Management)
Stream：位於server端，是代碼的交付目標，對具有權限的開發人員可見
Repository Workspace：位於server端，可以視作stream的個人鏡像
Local Workspace：本地工作空間，位於本地，與server端的Repository相關聯
開發人員無論是接受來自stream的變更還是向Stream交付本地發生的變更，都要通過中間層Repository Workspace，這樣做的好處是當開發人員修改了同一個文件時，可以在Repository Workspace提前發現沖突，避免都向Stream中提交變更時產生嚴重的沖突造成變更丟失或者代碼混亂。
開發人員的開發活動主要位於本地的工作空間，當有其他開發人員向Stream交付了新的變更，這個變更將顯示在個人的Repository Workspace 中，由開發人員自己決定是否接受這些變更，並下載到本地。
當開發人員在本地工作空間進行軟件開發活動，使得本地的workspace發生了變更，可以進行check-in操作向Repository Workspace check in發生的變更。再由Repository Workspace向Stream進行deliver操作完成變更的最終交付。
以下步驟圖描述了RTC中的版本控制流程
步驟1：
Developer 甲： Local 修改 -> Check-In -> Deliver to Stream
步驟2：
Developer 乙：Accept(Developer 甲的修改)from Steam-> Load 到 Local
▲圖13.RTC的版本控制流程
3.2.3 與Stream之間進行變更的交互更新
下圖顯示了pending changes中不同狀態的變更集：
▲圖14.Pending Changes中變更集的不同狀態
1) Unresolved 是可以 Check-In 的變更集
當用戶在 Local 更改了代碼文件時，就會出現 Unresolved 目錄，里面列出了所有的更改文件。開發者可以將更改過的文件，分成幾個不同的 Chang-Set 來 Check-In。
所有 Unresolved 的變更可以通過 Undo 來隨時撤銷。
▲圖15. Unresolved狀態的變更集可執行Ceck-in操作
2) Outgoing 是可以 Deliver 的變更集
當成功 Check-In 后，會在 Outgoing 目錄中出現等待 Deliver 的變更集。
對於還未 Deliver 的 Change-Set，開發者可以隨時再次修改，再次做 Check-In。
如果用戶想把這次 Check-In 的東西固定下來，再次修改的變更作為一個新的 Change-Set 的話。如圖15可以把已經 Check-In 的 Change-Set 標記為 Complete。就可以再次 Check-In 新的變更，而又不會影響到上次作的變更，會在 Outgoing 中出現 2 個針對同一文件的不同的 Chang-Set。這也正是 RTC 對於 Chang-Set 概念的優勢體現。
▲圖16.針對同一文件通過Complete操作chek-in兩次變更
當准備做 Deliver 的 Change-Set 與其他開發者的 Change-Set 有沖突時，RTC 中會顯示一個雙向箭頭標記，如圖16，這時候可以做 Discard 自己的 Change-Set 或者作 Merge。
▲圖17.處於沖突狀態的change-Set
3) Incoming是可以 Accept 的變更集
如果Local 已經 Load 過關於這個變更集的 Component，當開發者 Accept 一個變更集時，會自動 Load 到開發者本地的環境中去。如圖顯示為 loaded。
如果Local 沒有 Load 過關於這個變更集的 Component，那么 Accept 將只是在服務器端操作。
3.2.4 基線和快照功能
在repository space中右鍵選擇某一個component，可以創建baseline，baseline將會記錄component內文件的當前狀態，並可以在任何情況下方便的恢復到該baseline的狀態。
▲圖18.新建Baseline操作
右鍵選擇stream或者repository space，則可以對整個stream或者repository進行創建snapshot操作。
▲圖19.新建Snapshot操作
Snapshot將會記錄整個stream或者repository space的當前狀態。
而在Snapshots視圖中，可以選擇曾經創建的snapshot，方便地進行Stream或者repository space的重現工作。
▲圖20. 從Snapshot恢復Stream或Repository Wworkspace
RTC以其特有的三重工作空間模式和可視化的交付/接受變更視圖，實現了完備的代碼管理和版本控制功能，並能夠有效避免可能產生的沖突。其強大快速的baseline和snapshot功能，又為代碼安全可追溯和可恢復提供了保障。
3.3 構建管理 (Build Management)
RTC還提供了Build管理的功能。通過創建構建定義(Build Definition)和構建引擎(Build Engine)，RTC能夠發起對指定Stream的Build請求，並且調用腳本實現build過程。RTC還提供了與Rational BuildForge 工具的集成，可以借助BuildForge在自動化Build方面的強大功能完成代碼的Build工作。
▲圖21.新建Build Definition操作
▲圖22.新建Build Engines操作
小結：
本章介紹了RTC應用於軟件開發活動中的一般模式，着重介紹了開發人員使用RTC進行代碼版本控制的流程。同時也對RTC用於項目管理和構建管理作了簡略介紹。
總結
RTC作為新一代的軟件交付協作環境，為軟件開發團隊提供了從需求到計划，從開發到最終交付的完整平台。它提供的功能豐富而靈活，一個團隊如果能夠熟練運用RTC進行軟件開發活動的支持管理，必將大大提高生產效率，減少管理和溝通協作的成本，它強大的代碼管理和版本控制功能也為軟件開發團隊很好地解決了協作開發中繁瑣而復雜的問題。本文將RTC應用於軟件開發活動的一些經驗進行分享，為軟件開發團隊提供一定的借鑒，希望RTC這個強大的工具能夠更好地支持軟件開發團隊的工作，交付更多更好的產品。