敏捷軟件配置管理與 IBM Rational 工具集

本文來自于 Rational Edge：本文討論了敏捷軟件配置管理（Agile Software Configuration Management）的概念，一種適合于敏捷開發方法的 SCM 風格。文中還介紹了IBM Rational SCM 工具集如何實現敏捷軟件配置管理，以支持敏捷項目。

并不久以前，敏捷開發方法，例如極限編程（eXtreme Programming，XP）、動態系統開發方法（Dynamic Systems Development Method，DSDM），或 Scrum 作為新的且稍微有爭議的軟件開發項目的交付方法被引入。如今，敏捷開發實踐，例如迭代開發、測試驅動的開發，和持續的集成成為了普遍現象，并且人們已經接受并采用它們作為另一種軟件開發的方法。不論您的看法或經驗是什么，您不能否認的是，敏捷開發項目可以并且已經證明能夠成功，準時，并按照預算交付功能。 ¹

本文討論了敏捷開發的具體方面 —— 敏捷軟件配置管理，或簡稱“敏捷 SCM”的概念，一個精心設計的輕型 SCM，可以由軟件開發項目使用和實踐敏捷開發方法。作為此討論的一部分，我還將關注企業級 SCM 工具集，例如 IBM Rational SCM 工具集，能夠如何實現，以支持敏捷項目。

敏捷開發

大多數敏捷開發方法所共用的方法是讓用戶或客戶直接參與并與之交流，并且在頻繁的，短期的迭代（典型的為二到十二個星期）中進行功能開發。典型的是，在每個迭代的開始，敏捷團隊會與客戶商談來確定新的特性或變更請求。這些由開發人員進行估計，并且隨后，由客戶為下一次迭代設置優先級，如圖 1 中所示。任何還沒有在迭代中實現的特性或變更請求將與所有新的請求一起保留下來，并且由客戶為下一次迭代重新設定優先級。允許開發人員致力于當前迭代的請求，或者在必要時重構并簡化現存的代碼。這樣做的意圖是，保持設計的簡單，并且防止不必要的特性膨脹。代碼還是不斷地集成的，并頻繁地以很小的單位進行實現、測試及提交，這可以利用在提交時刻調用的自動化構建過程來檢查集成錯誤。

圖 1：在每個迭代的開始，敏捷團隊會與客戶商談來確定新的特性或變更請求。這些由開發人員進行估計，并且隨后，由客戶為下一次迭代設置優先級。

如同所有軟件開發過程，敏捷開發方法需要一個基于核心及支持團隊的環境，一些在傳統上稱為軟件配置管理，或 SCM 的東西。不幸的是，一些實踐者將 SCM 看作是一個陳舊的且不必要的控制規程。但這是一個誤解。雖然事實上過多的喝錯誤類型的 SCM 可以扼殺敏捷開發項目，但是敏捷實踐，例如迭代開發和持續集成，如果沒有 SCM 將不會成功這也是事實。

因此，對于這些類型的項目，您需要多少，以及什么類型的 SCM？要回答這些問題，讓我們引入一個相對新的概念：敏捷 SCM（Agile SCM）。

敏捷 SCM

敏捷 SCM 概念本身可能是由 Brad Appleton 和 Stephen Berczuk 在他們的書 Software Configuration Management Patterns 中 和 SCM portal CM Crossroads 中被首次進行了詳細地討論。 ² 其中一個觀察是：

...配置管理在利用平衡且有效的 SCM 過程集方面成為關鍵的“支柱”并且也是敏捷開發方法的標準。“敏捷倡導者”著重強調在敏捷項目上應用瘦的及輕型的 配置管理（CM），這將需要更少的打擾/入侵（Grady Booch 所謂的低摩擦），以使敏捷項目能夠成功，而與此同時配置管理有不能太?。ㄓ捎谶^度反應）以至于導致項目失敗。

與我剛才的觀點一致的是，雖然敏捷項目上的 SCM 趨向于更加輕型且更少的可見性，但是 SCM 本身是此類項目的關鍵需求。也許不一致的是，大多數敏捷項目采用入門級或輕型的 SCM 工具，例如 CVS、Subversion，或 BitKeeper —— 這些工具有局限性但基本上擁有滿足敏捷項目的功能。它們也是趨向于較小的影響并且重視開發經驗的工具，而不是對一個嚴格控制過程的遵循。

然而，理論上，您沒有理由不能使用 SCM 工具來支持敏捷開發實踐。您當然不必要使用工具的所有特性，并且大多數工具允許某種程度上的過程定制化，從重量級到輕量級的，以及兩者之間的任意程度。有了企業級工具，例如 IBM Rational ClearCase，一些組織總想使用所有的“突出特性”來定義重量級的 SCM 過程，只因為該工具提供支持。然而，這樣的過程對滿足您項目的需求是不必要的。要找到正確的過程和定制級別，您應該首先確定并定義您的需求，這意味著確切地了解您的開發過程是什么，或者應該是什么，然后確定 SCM 如何提供支持。

一般來說，SCM 是關于開發過程“管理”的，換句話說，SCM 允許項目保留控制措施，而與此同時又能夠允許開發人員在過程中擁有創建的自由度。利用敏捷開發方法，開發人員擁有高度的自由和權利來實現變更。然而，持續集成和測試驅動的開發實踐的一個結果是，它們實際上形成了一個規劃良好的并且幾乎自治的 SCM 方法。例如，在每個代碼變更時，敏捷開發人員必須首先撰寫一個單元測試，然后撰寫足夠的代碼使測試能夠工作，隨后按照需要的重構以完成該變更。提交（或檢入）代碼變更，并且代碼變更的單元測試成為集成套件中的一個部分。通過集成構建機制編譯和執行完整的單元測試套件，可以直接可視化地看到變更的所有副作用 —— 所有找到的問題都能夠立即修改。

在敏捷 SCM 中，該管理模型是日常開發活動的正常部分，并且因此對開發人員是相當透明的。要更詳細地了解此管理模型，讓我們看看 SCM 的一些不同的特征，以及如何典型地實現它們來支持敏捷開發方法：

• 分支。敏捷項目實現簡單的分支策略，典型的是活動開發線（Active Development Line） ³ 和版本預備線（Release Prep Line）?；顒娱_發線由開發人員用來提交他們的變更并且持續集成構建通過此方法來執行。版本預備線是用于在客戶使用之前穩定化或工程化一個版本的，通常不允許開發人員向它提交變更。
• 工作區。開發人員擁有一個單個私有的工作區，最初指向活動開發線最新版本的集合。在開發人員開始致力于新的特性或變更請求時，并且就在他們向活動開發線提交變更來檢查集成問題之前他們的工作區以最小量更新著。
• 標簽。如傳統的 SCM 一樣，標簽放置在代碼版本集合重要的里程碑上，在每個版本構建上至少有一個標簽，以便在必要時能夠重新產生構建環境。
• 構建和集成。成功的敏捷開發的關鍵因素是自動化的構建過程。構建過程監控關于提交的活動開發線，在一個較寬松的限期自動地執行集成構建和單元測試。該構建成功或失敗的通知是敏捷團隊中關鍵的通信因素。
• 變更控制。如早先討論的一樣，一個隱含的授權過程伴隨著敏捷開發團隊，授權開發人員做出基于客戶優先級的變更，或者在必要時重構。請求要么記錄在變更控制系統中，要么對于更不正式的項目來說，特別是在極限程序設計項目中，記錄在卡片上或活動掛圖上。

雖然這些 SCM 特性典型地處在敏捷過程中，但是它們很可能根據特定項目所需的敏捷程度而“調整”。例如，一些項目也許不能構建在每個提交上，取而代之的是計劃一個單個的每日或每夜的集成構建。還有，項目不是獨立存在的，它們通常是組織中許多項目中的一個。企業組織中常?；旌嫌忻艚莺蛡鹘y的計劃驅動的項目，并且因此一個已知的項目可能存在于特定的市場區段中。該企業環境常常是決定選擇哪個 SCM 工具集并且所選工具集需要支持哪些額外的管理方面的最大的因素。

敏捷 SCM 和企業

如果您孤立地看一個單個的敏捷項目，那么它的 SCM 需求幾乎肯定地可以由相當簡單的工具集來滿足。項目本身就可以使用并管理這樣的工具集。然而，與其支持具體項目的工具集相比，大多數大型組織更喜歡將單個的 SCM 工具集標準化，并且圍繞它開發組織過程。這樣做有兩個主要原因：

• 減少工具集及其過程的所有權的總成本
• 能夠符合所期望的（或強制的）一致性或規章制度框架

所有權的總成本常常是主觀問題，因為其包含許多可以計量的方面，例如許可、管理，和支持成本，以及其他主觀方法，例如功能或可伸縮性。企業級工具集，例如 IBM Rational 工具集經常有更高的許可、管理，和支持成本（最初時是當然的），但如果正確地實現了，這些企業工具集可以總體地提高組織能力。它們還擁有已證實的可伸縮性，一個單個的、統一的基礎結構能夠支持大型的，地理上分散的開發組織。如上面所提到的，這類工具的主要危險是試圖使用超過所需的更多功能，這樣會扼殺敏捷項目。需要建立一個組織的 SCM 框架，并且應該以某種可配置的方式來實現，以便滿足不同項目的需求。

最近的行業法規，例如 Sarbanes Oxley、Basel II，和 CFR 21 Part 11 會向 SCM 過程施加繁重的管理成本，特別是關于變更控制的方面。雖然實踐，例如“職責的分離”—— 不允許開發人員部署到實際的環境中 —— 應該實現，但是對敏捷項目嚴格強制實施變更控制會扼殺它們。然而，不滿足這些法規的商業成本是巨大的，因此雖然敏捷項目可能希望避免不必要的管理實踐，但是它們不得不在大多數情況下接受一些額外的開銷。好的消息是，如果實現的正確，那么自動化的 SCM 工具集可以實現大多數的管理方面，使商家維持組織的控制，而又允許單個項目和它們的開發人員致力于有創造性地開發新的軟件功能來解決商業問題。

用 IBM Rational 工具集實現敏捷 SCM

讓我們來考慮，對于使用 IBM Rational 工具集的敏捷項目來說，管理的嚴格性和靈活性之間的平衡如何能夠被達到呢？

一個普遍的誤解是企業級 SCM 工具集 —— 例如 IBM Rational 工具集 —— 不能用于支持實現敏捷開發方法。這些工具集中所提供的重要功能是來支持許多不同的類型和大小的開發環境的，因此，確定該功能的哪個要素應該使用是不容易的，并且存在的一個風險是，對 SCM 過程將進行過渡的設計。目前，在 IBM Rational SCM 工具集中還不存在現成的敏捷 SCM 配置。取而代之，留給工具集實施者的是找到滿足其需求的適當的配置。

好消息是，在 IBM Rational 工具集的支撐下，許多組織已經設法找到了這種配置，并且將成功地實現敏捷開發方法。從觀察來看，有許多這些項目所共用的最佳實踐。雖然這些最佳實踐不是絕對的，但是它們應該足以給您一個框架及實現您自己的敏捷 SCM 過程的起始點。它們可以如下概括為：

• 實現一個簡化的分支策略。敏捷項目實現簡單的分支策略。在 Base ClearCase 和 ClearCase UCM（統一的變更管理，Unified Change Management）中，分支（UCM 術語中的“流”）可以很容易且很廉價地生成。因此經常會有這樣的趨勢，定義比確切需要的更復雜的分支策略。敏捷項目積極地鼓勵持續集成和重構，但是開發人員孤立于分支上，那么將出現有問題的或復雜的合并操作。這在命名空間重構（重命名、添加，或刪除文件或目錄）的情況下尤為正確。因此，大多數敏捷項目實現一個特定的分支，作為活動開發線，并且開發人員直接處理的上面的內容。在 Base ClearCase 中，這要么是主分支，要么是具體的項目集成分支，在 UCM 中，這是 UCM 項目的集成流。要隔離一個版本的環境，也會實現一個版本準備線。通過創建一個擁有可以放置在活動開發線之下的候選標簽（或者 UCM 基線）的版本分支（或 UCM 流）來實現。該標簽將手動地生成 —— 或者更可能自動化地 —— 作為集成構建的一部分。說明此結構的圖如圖 2 所示。
  
  
  
  圖 2：要隔離一個版本的環境，通過創建一個擁有可以放置在活動開發線之下的候選標簽（或者 UCM 基線）的版本分支（或 UCM 流）來實現一個版本準備線。該標簽將手動地生成 —— 或者更可能自動化地 —— 作為集成構建的一部分。
  
  敏捷項目不但提供簡化的分支策略，它還傾向于配置 ClearCase 默認為“無限制的”檢出模型。這允許開發人員檢出和檢入一個活動開發線上任意點上的文件（雖然如果在此期間另一個開發人員也檢出和檢入同樣的文件，應該對這些進行一些合并）。默認的 ClearCase 模型對于第一次的檢出是“受限制的”。這意味著，您不需要必須合并而保證能夠將元素檢入回去。然而，這還意味著，其他人不能檢出受限制的元素，直到您將其放回為止，檢出無限制元素的人必須等待在合并之前您將該元素檢入回去。這種方法真的違反敏捷原則。
• 使用快照視圖開發人員工作區。如果開發人員將要致力于單一的分支，那么不用選擇動態的視圖。動態視圖的能力在于當它們監測的分支更新時，它們可以自動地更新自己。因此，如果許多開發人員在單個的分支上加上動態的視圖，那么在它們的工作區中幾乎不能控制或隔離。雖然開發人員分支不能實現，如我們已經討論過的，但這可以導致其他的問題。因此敏捷項目會實現快照視圖，從中開發人員可以更新他們的工作區來從其他開發人員那里引入變更。在實踐中，這給予開發人員足夠的控制和隔離。
• 自動化構建過程。單個的分支開發和增量的的檢入只有在頻繁地執行自動化的構建和測試時才能夠實行。大多數敏捷項目將它們的構建過程配置為在每個開發人人員的檢入之上執行。除了編譯代碼，這種構建過程還驗證新的代碼，用以觀察代碼是否符合預定義的編碼習慣，并且在必要處執行單元測試。在敏捷開發方法中，該實踐常稱為持續集成。其預期的結果是為了盡早地暴露集成問題，以便容易地處理，以及在項目的每個階段都有建立好的、測試了的，以及可能的可發布的構建。持續集成常常與測試驅動的開發實踐雜亂的鏈接在一起。這是因為開發人員需要對其代碼的所有方面實現單元測試來驗證構建已經編譯了，以及符合最低水平的功能質量。在 ClearCase 術語中，敏捷項目構建過程用于監控集成分支（或 UCM 流）以及在檢入時執行構建教本。這由構建執行工具，例如 CruiseControl（http://cruisecontrol.sourceforge.net）或 IBM Rational BuildForge（http://www.ibm.com/software/rational/buildmanagement/）來實行。 ⁴
• 執行并再利用預構建好的二進制碼。構建任何相當復雜的軟件應用程序都會花費時間，從幾分鐘到幾小時。在敏捷項目中，開發人員將會經常交付并集成小的變更，因此很顯然他們不可能在得到反饋之前等待兩小時完成構建操作。為了避免這種情況，敏捷項目“執行”并再利用預構建好的二進制碼，并且只有再必要時重新構建整個系統（例如，每夜或每周）。有許多方式來執行二進制碼。ClearCase 常常用于執行二進制碼，標簽或基線設置在相關的版本之下，來指示可復用的二進制碼的復合集。對于 C/C++ 項目，ClearCase clearmake 實用程序也擁有一個避免構建的機制，可以用于將大部分這種執行自動化并再利用過程，雖然沒有證據證明敏捷項目使用此機制。對于 Java 項目，另一種方法是，在相關管理工具，例如 Ivy（http://jayasoft.org/ivy）或 Maven（http://maven.apache.org）中執行預構建好的庫。當項目再利用大量開源組件時，或在傳遞相關性方面存在問題時（也就是，庫依賴于其他的庫）這一點尤為適當。
• 作為復合的應用程序而發布。當說到發布應用程序時，試圖發布所有的文件，而不是發布個別集合。大多數敏捷項目更喜歡每次部署全部的或復合的應用程序，而不是只部署已經變更的個別的文件。雖然這不是硬性規定，每次以同樣的方式發布全部的應用程序趨向于使過程更加可重復并且防止文件丟失所導致的問題。該實踐對敏捷項目比對高要求形式的項目更為重要，因為它們在每次迭代之后生成可執行的、可測試的，并且可發布的應用程序。很明顯，這依賴于應用程序的目標環境。如果是 Web 門戶，那么該方法很好，但如果是一個消費者應用程序（運行在，比方說，Microsoft Windows 上），那么完整的版本不可能每次都給客戶，所以就需要每次一個補丁。
• 限制 MultiSite 技術的使用。分布式的敏捷項目需要無限制的對單個代碼行的訪問。ClearCase MultiSite 技術從站點到站點復制完整的數據庫。為了避免每個站點所做出的變更的沖突，其實現了一個所謂 mastership（主權） 的概念。這意味著如果一個項目在多個站點上開發，并且開發人員正共用同一個分支，那么每個開發人員在提交變更之前要請求主權。有許多方法來處理這件事（包括創建基于站點的集成分支），但它們都增加了額外層次的復雜度，并且會減慢開發過程。出于這些原因，敏捷項目傾向于避免 MultiSite 技術。這就是為什么開發了 ClearCase Remote Client (CCRC) 技術，它允許基于脫離單個服務器的分布式開發。CCRC 的第一個版本限制了功能，然而，從版本 7.0 開始，它將對大多數分布式項目提供足夠的功能。因此它應該成為進行分布式靈活項目的推薦方法。圖 3 中的屏幕快照說明了工作于 Eclipse 環境中的 ClearCase Remote Client。

圖 3：工作于 Eclipse 環境中的 ClearCase Remote Client

• 避免 ClearQuest 變更控制的過度自定義。實現一個開放的或可定制的變更請求工作流。IBM Rational ClearQuest 工具提供非常強大且成熟的變更和缺陷跟蹤工具。雖然許多使用 ClearCase 的敏捷項目已經完全避免使用 ClearQuest 的了，但是越來越多的項目在著眼于 ClearQuest 以及 UCM，看看是否可以用于幫助滿足組織遵從和法規的需求。的確，ClearQuest 可以在自動化獲取、劃分優先級，及變更請求和特性儲備的分配上占有地位，如我在本文開頭所提到的。然而，過多的過程強制或過小的管理會令開始致力于新的變更任務的開發人員感到時間緊迫。如果不小心實行，這會嚴重地減慢整個開發過程并減少敏捷項目的生產率。為了避免這一點，敏捷項目實現輕量級的或可定制的 ClearQuest 變更請求工作流。當 ClearQuest 用于整個組織中時，這是尤為恰當的。在那些組織中的一些項目可能會需要更多的控制和管理，許多會嵌入 ClearQuest 工具中。然而，敏捷項目可能不需要或期望同等程度的過程控制和管理。在這種環境中工作的組織通過令變更請求工作流可以讓每個項目來配置而取得成功。然而，這種實現需要對 ClearQuest 工具和不同項目過程需求的詳細了解，并且應該不容易著手。

適合于敏捷方法的過程

在本文中，我已經討論了敏捷 SCM 的概念以及如何利用 IBM Rational ClearCase 和 IBM Rational ClearQuest 來實現的最佳實踐。希望該討論可以使您確信，可以找到并實現合適的過程來支持敏捷項目。值得注意的是敏捷 SCM 的實現不是只限于敏捷項目的。有許多項目不認為自己是敏捷的，但已經有類似的 SCM 需求。這些趨向于較小的 IS/IT 項目，類似環境的配置會非常實際。但值得注意的是甚至是較大的項目也可以通過實現更輕量級的且精心設計的 SCM 過程，例如這里所介紹的，來得到一些東西。特別是，構建自動化（包括編譯和測試）、預構建好的二進制碼的執行，和復合發布的實踐可被所有項目采用。

沒有理由說企業級 SCM 工具集，例如 IBM Rational 工具集，不能用于支持敏捷開發方法的實現。關鍵是，定義并實現一個著重于支持，而不是限制，敏捷團隊的敏捷 SCM 過程。對于這樣的團隊，找到正確的管理模型會是一個棘手的訓練，但是一般建議從更開放的過程開始，只在必要時實現限制。反饋也是敏捷開發方法的必要部分。SCM 可以有助于此反饋機制的一種方式是通過自動化的構建和測試（及部署）過程。因此推薦您投入大量時間關注您整個過程中的這個方面。

注釋

¹ 要了解敏捷和傳統的開發方法相對比的優缺點和成功方面的討論，請參見 Barry Boehm 和 Richard Turner 的優秀書籍，Balancing Agility and Discipline: A Guide for the Perplexed: Addison Wesley 2004 年。另外，要了解關于敏捷開發方法的最新討論和案例研究，您可以訪問并訂閱The Agile Journal（http://www.agilejournal.com）。

² Stephen P. Berczuk 和 Brad Appleton，Software Configuration Management Patterns. Effective Teamwork, Practical Integration。 Addison Wesley 2003 年。另參見 Brad Appleton et al.，Streamed Lines: Branching Patterns for Parallel Software Development。PLoP Conference：1998 年。http://www.cmcrossroads.com/bradapp/acme/branching/

³ 參見 Appleton，1998 年，Op. cit。

⁴ 要了解更多關于如何為敏捷項目設立自動化的構建環境的信息，請參見 Kevin A. Lee，IBM Rational ClearCase, Ant and CruiseControl。The Java Developers Guide to Aclearcase/" target="_blank" >ccelerating and Automating the build process。 Addison Wesley 2006 年。

原文轉自：http://www.kjueaiud.com