本文來(lái)自于 Rational Edge：本文討論了敏捷軟件配置管理（Agile Software Configuration Management）的概念，一種適合于敏捷開(kāi)發(fā)方法的 SCM 風(fēng)格。文中還介紹了IBM Rational SCM 工具集如何實(shí)現(xiàn)敏捷軟件配置管理，以支持敏捷項(xiàng)目。

　　并不久以前，敏捷開(kāi)發(fā)方法，例如極限編程（eXtreme Programming，XP）、動(dòng)態(tài)系統(tǒng)開(kāi)發(fā)方法（Dynamic Systems Development Method，DSDM），或 Scrum 作為新的且稍微有爭(zhēng)議的軟件開(kāi)發(fā)項(xiàng)目的交付方法被引入。如今，敏捷開(kāi)發(fā)實(shí)踐，例如迭代開(kāi)發(fā)、測(cè)試驅(qū)動(dòng)的開(kāi)發(fā)，和持續(xù)的集成成為了普遍現(xiàn)象，并且人們已經(jīng)接受并采用它們作為另一種軟件開(kāi)發(fā)的方法。不論您的看法或經(jīng)驗(yàn)是什么，您不能否認(rèn)的是，敏捷開(kāi)發(fā)項(xiàng)目可以并且已經(jīng)證明能夠成功，準(zhǔn)時(shí)，并按照預(yù)算交付功能。

　　本文討論了敏捷開(kāi)發(fā)的具體方面 —— 敏捷軟件配置管理，或簡(jiǎn)稱“敏捷 SCM”的概念，一個(gè)精心設(shè)計(jì)的輕型 SCM，可以由軟件開(kāi)發(fā)項(xiàng)目使用和實(shí)踐敏捷開(kāi)發(fā)方法。作為此討論的一部分，我還將關(guān)注企業(yè)級(jí) SCM 工具集，例如 IBM Rational SCM 工具集，能夠如何實(shí)現(xiàn)，以支持敏捷項(xiàng)目。

敏捷開(kāi)發(fā)

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

圖 1：在每個(gè)迭代的開(kāi)始，敏捷團(tuán)隊(duì)會(huì)與客戶商談來(lái)確定新的特性或變更請(qǐng)求。這些由開(kāi)發(fā)人員進(jìn)行估計(jì)，并且隨后，由客戶為下一次迭代設(shè)置優(yōu)先級(jí)。

　　如同所有軟件開(kāi)發(fā)過(guò)程，敏捷開(kāi)發(fā)方法需要一個(gè)基于核心及支持團(tuán)隊(duì)的環(huán)境，一些在傳統(tǒng)上稱為軟件配置管理，或 SCM 的東西。不幸的是，一些實(shí)踐者將 SCM 看作是一個(gè)陳舊的且不必要的控制規(guī)程。但這是一個(gè)誤解。雖然事實(shí)上過(guò)多的喝錯(cuò)誤類型的 SCM 可以扼殺敏捷開(kāi)發(fā)項(xiàng)目，但是敏捷實(shí)踐，例如迭代開(kāi)發(fā)和持續(xù)集成，如果沒(méi)有 SCM 將不會(huì)成功這也是事實(shí)。

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

敏捷 SCM

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

　　配置管理在利用平衡且有效的 SCM 過(guò)程集方面成為關(guān)鍵的“支柱”并且也是敏捷開(kāi)發(fā)方法的標(biāo)準(zhǔn)。“敏捷倡導(dǎo)者”著重強(qiáng)調(diào)在敏捷項(xiàng)目上應(yīng)用瘦的及輕型的 配置管理（CM），這將需要更少的打擾/入侵（Grady Booch 所謂的低摩擦），以使敏捷項(xiàng)目能夠成功，而與此同時(shí)配置管理有不能太?。ㄓ捎谶^(guò)度反應(yīng)）以至于導(dǎo)致項(xiàng)目失敗。與我剛才的觀點(diǎn)一致的是，雖然敏捷項(xiàng)目上的 SCM 趨向于更加輕型且更少的可見(jiàn)性，但是 SCM 本身是此類項(xiàng)目的關(guān)鍵需求。也許不一致的是，大多數(shù)敏捷項(xiàng)目采用入門級(jí)或輕型的 SCM 工具，例如 CVS、Subversion，或 BitKeeper —— 這些工具有局限性但基本上擁有滿足敏捷項(xiàng)目的功能。它們也是趨向于較小的影響并且重視開(kāi)發(fā)經(jīng)驗(yàn)的工具，而不是對(duì)一個(gè)嚴(yán)格控制過(guò)程的遵循。

　　然而，理論上，您沒(méi)有理由不能使用 SCM 工具來(lái)支持敏捷開(kāi)發(fā)實(shí)踐。您當(dāng)然不必要使用工具的所有特性，并且大多數(shù)工具允許某種程度上的過(guò)程定制化，從重量級(jí)到輕量級(jí)的，以及兩者之間的任意程度。有了企業(yè)級(jí)工具，例如 IBM Rational ClearCase，一些組織總想使用所有的“突出特性”來(lái)定義重量級(jí)的 SCM 過(guò)程，只因?yàn)樵摴ぞ咛峁┲С?。然而，這樣的過(guò)程對(duì)滿足您項(xiàng)目的需求是不必要的。要找到正確的過(guò)程和定制級(jí)別，您應(yīng)該首先確定并定義您的需求，這意味著確切地了解您的開(kāi)發(fā)過(guò)程是什么，或者應(yīng)該是什么，然后確定 SCM 如何提供支持。

　　一般來(lái)說(shuō)，SCM 是關(guān)于開(kāi)發(fā)過(guò)程“管理”的，換句話說(shuō)，SCM 允許項(xiàng)目保留控制措施，而與此同時(shí)又能夠允許開(kāi)發(fā)人員在過(guò)程中擁有創(chuàng)建的自由度。利用敏捷開(kāi)發(fā)方法，開(kāi)發(fā)人員擁有高度的自由和權(quán)利來(lái)實(shí)現(xiàn)變更。然而，持續(xù)集成和測(cè)試驅(qū)動(dòng)的開(kāi)發(fā)實(shí)踐的一個(gè)結(jié)果是，它們實(shí)際上形成了一個(gè)規(guī)劃良好的并且?guī)缀踝灾蔚?SCM 方法。例如，在每個(gè)代碼變更時(shí)，敏捷開(kāi)發(fā)人員必須首先撰寫一個(gè)單元測(cè)試，然后撰寫足夠的代碼使測(cè)試能夠工作，隨后按照需要的重構(gòu)以完成該變更。提交（或檢入）代碼變更，并且代碼變更的單元測(cè)試成為集成套件中的一個(gè)部分。通過(guò)集成構(gòu)建機(jī)制編譯和執(zhí)行完整的單元測(cè)試套件，可以直接可視化地看到變更的所有副作用 —— 所有找到的問(wèn)題都能夠立即修改。

　　在敏捷 SCM 中，該管理模型是日常開(kāi)發(fā)活動(dòng)的正常部分，并且因此對(duì)開(kāi)發(fā)人員是相當(dāng)透明的。要更詳細(xì)地了解此管理模型，讓我們看看 SCM 的一些不同的特征，以及如何典型地實(shí)現(xiàn)它們來(lái)支持敏捷開(kāi)發(fā)方法：

　　·分支。敏捷項(xiàng)目實(shí)現(xiàn)簡(jiǎn)單的分支策略，典型的是活動(dòng)開(kāi)發(fā)線（Active Development Line） 3 和版本預(yù)備線（Release Prep Line）?；顒?dòng)開(kāi)發(fā)線由開(kāi)發(fā)人員用來(lái)提交他們的變更并且持續(xù)集成構(gòu)建通過(guò)此方法來(lái)執(zhí)行。版本預(yù)備線是用于在客戶使用之前穩(wěn)定化或工程化一個(gè)版本的，通常不允許開(kāi)發(fā)人員向它提交變更。
　　·工作區(qū)。開(kāi)發(fā)人員擁有一個(gè)單個(gè)私有的工作區(qū)，最初指向活動(dòng)開(kāi)發(fā)線最新版本的集合。在開(kāi)發(fā)人員開(kāi)始致力于新的特性或變更請(qǐng)求時(shí)，并且就在他們向活動(dòng)開(kāi)發(fā)線提交變更來(lái)檢查集成問(wèn)題之前他們的工作區(qū)以最小量更新著。
　　·標(biāo)簽。如傳統(tǒng)的 SCM 一樣，標(biāo)簽放置在代碼版本集合重要的里程碑上，在每個(gè)版本構(gòu)建上至少有一個(gè)標(biāo)簽，以便在必要時(shí)能夠重新產(chǎn)生構(gòu)建環(huán)境。
　　·構(gòu)建和集成。成功的敏捷開(kāi)發(fā)的關(guān)鍵因素是自動(dòng)化的構(gòu)建過(guò)程。構(gòu)建過(guò)程監(jiān)控關(guān)于提交的活動(dòng)開(kāi)發(fā)線，在一個(gè)較寬松的限期自動(dòng)地執(zhí)行集成構(gòu)建和單元測(cè)試。該構(gòu)建成功或失敗的通知是敏捷團(tuán)隊(duì)中關(guān)鍵的通信因素。
　　·變更控制。如早先討論的一樣，一個(gè)隱含的授權(quán)過(guò)程伴隨著敏捷開(kāi)發(fā)團(tuán)隊(duì)，授權(quán)開(kāi)發(fā)人員做出基于客戶優(yōu)先級(jí)的變更，或者在必要時(shí)重構(gòu)。請(qǐng)求要么記錄在變更控制系統(tǒng)中，要么對(duì)于更不正式的項(xiàng)目來(lái)說(shuō)，特別是在極限程序設(shè)計(jì)項(xiàng)目中，記錄在卡片上或活動(dòng)掛圖上。

　　雖然這些 SCM 特性典型地處在敏捷過(guò)程中，但是它們很可能根據(jù)特定項(xiàng)目所需的敏捷程度而“調(diào)整”。例如，一些項(xiàng)目也許不能構(gòu)建在每個(gè)提交上，取而代之的是計(jì)劃一個(gè)單個(gè)的每日或每夜的集成構(gòu)建。還有，項(xiàng)目不是獨(dú)立存在的，它們通常是組織中許多項(xiàng)目中的一個(gè)。企業(yè)組織中常常混合有敏捷和傳統(tǒng)的計(jì)劃驅(qū)動(dòng)的項(xiàng)目，并且因此一個(gè)已知的項(xiàng)目可能存在于特定的市場(chǎng)區(qū)段中。該企業(yè)環(huán)境常常是決定選擇哪個(gè) SCM 工具集并且所選工具集需要支持哪些額外的管理方面的最大的因素。

　　敏捷 SCM 和企業(yè)

　　如果您孤立地看一個(gè)單個(gè)的敏捷項(xiàng)目，那么它的 SCM 需求幾乎肯定地可以由相當(dāng)簡(jiǎn)單的工具集來(lái)滿足。項(xiàng)目本身就可以使用并管理這樣的工具集。然而，與其支持具體項(xiàng)目的工具集相比，大多數(shù)大型組織更喜歡將單個(gè)的 SCM 工具集標(biāo)準(zhǔn)化，并且圍繞它開(kāi)發(fā)組織過(guò)程。這樣做有兩個(gè)主要原因：

　　·減少工具集及其過(guò)程的所有權(quán)的總成本
　　·能夠符合所期望的（或強(qiáng)制的）一致性或規(guī)章制度框架

　　所有權(quán)的總成本常常是主觀問(wèn)題，因?yàn)槠浒S多可以計(jì)量的方面，例如許可、管理，和支持成本，以及其他主觀方法，例如功能或可伸縮性。企業(yè)級(jí)工具集，例如 IBM Rational 工具集經(jīng)常有更高的許可、管理，和支持成本（最初時(shí)是當(dāng)然的），但如果正確地實(shí)現(xiàn)了，這些企業(yè)工具集可以總體地提高組織能力。它們還擁有已證實(shí)的可伸縮性，一個(gè)單個(gè)的、統(tǒng)一的基礎(chǔ)結(jié)構(gòu)能夠支持大型的，地理上分散的開(kāi)發(fā)組織。如上面所提到的，這類工具的主要危險(xiǎn)是試圖使用超過(guò)所需的更多功能，這樣會(huì)扼殺敏捷項(xiàng)目。需要建立一個(gè)組織的 SCM 框架，并且應(yīng)該以某種可配置的方式來(lái)實(shí)現(xiàn)，以便滿足不同項(xiàng)目的需求。

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

用 IBM Rational 工具集實(shí)現(xiàn)敏捷 SCM

　　讓我們來(lái)考慮，對(duì)于使用 IBM Rational 工具集的敏捷項(xiàng)目來(lái)說(shuō)，管理的嚴(yán)格性和靈活性之間的平衡如何能夠被達(dá)到呢？

　　一個(gè)普遍的誤解是企業(yè)級(jí) SCM 工具集 —— 例如 IBM Rational 工具集 —— 不能用于支持實(shí)現(xiàn)敏捷開(kāi)發(fā)方法。這些工具集中所提供的重要功能是來(lái)支持許多不同的類型和大小的開(kāi)發(fā)環(huán)境的，因此，確定該功能的哪個(gè)要素應(yīng)該使用是不容易的，并且存在的一個(gè)風(fēng)險(xiǎn)是，對(duì) SCM 過(guò)程將進(jìn)行過(guò)渡的設(shè)計(jì)。目前，在 IBM Rational SCM 工具集中還不存在現(xiàn)成的敏捷 SCM 配置。取而代之，留給工具集實(shí)施者的是找到滿足其需求的適當(dāng)?shù)呐渲谩?/p>

　　好消息是，在 IBM Rational 工具集的支撐下，許多組織已經(jīng)設(shè)法找到了這種配置，并且將成功地實(shí)現(xiàn)敏捷開(kāi)發(fā)方法。從觀察來(lái)看，有許多這些項(xiàng)目所共用的最佳實(shí)踐。雖然這些最佳實(shí)踐不是絕對(duì)的，但是它們應(yīng)該足以給您一個(gè)框架及實(shí)現(xiàn)您自己的敏捷 SCM 過(guò)程的起始點(diǎn)。它們可以如下概括為：

　　實(shí)現(xiàn)一個(gè)簡(jiǎn)化的分支策略。敏捷項(xiàng)目實(shí)現(xiàn)簡(jiǎn)單的分支策略。在 Base ClearCase 和 ClearCase UCM（統(tǒng)一的變更管理，Unified Change Management）中，分支（UCM 術(shù)語(yǔ)中的“流”）可以很容易且很廉價(jià)地生成。因此經(jīng)常會(huì)有這樣的趨勢(shì)，定義比確切需要的更復(fù)雜的分支策略。敏捷項(xiàng)目積極地鼓勵(lì)持續(xù)集成和重構(gòu)，但是開(kāi)發(fā)人員孤立于分支上，那么將出現(xiàn)有問(wèn)題的或復(fù)雜的合并操作。這在命名空間重構(gòu)（重命名、添加，或刪除文件或目錄）的情況下尤為正確。因此，大多數(shù)敏捷項(xiàng)目實(shí)現(xiàn)一個(gè)特定的分支，作為活動(dòng)開(kāi)發(fā)線，并且開(kāi)發(fā)人員直接處理的上面的內(nèi)容。在 Base ClearCase 中，這要么是主分支，要么是具體的項(xiàng)目集成分支，在 UCM 中，這是 UCM 項(xiàng)目的集成流。要隔離一個(gè)版本的環(huán)境，也會(huì)實(shí)現(xiàn)一個(gè)版本準(zhǔn)備線。通過(guò)創(chuàng)建一個(gè)擁有可以放置在活動(dòng)開(kāi)發(fā)線之下的候選標(biāo)簽（或者 UCM 基線）的版本分支（或 UCM 流）來(lái)實(shí)現(xiàn)。該標(biāo)簽將手動(dòng)地生成 —— 或者更可能自動(dòng)化地 —— 作為集成構(gòu)建的一部分。說(shuō)明此結(jié)構(gòu)的圖如圖 2 所示?！　?/p>

圖 2：要隔離一個(gè)版本的環(huán)境，通過(guò)創(chuàng)建一個(gè)擁有可以放置在活動(dòng)開(kāi)發(fā)線之下的候選標(biāo)簽（或者 UCM 基線）的版本分支（或 UCM 流）來(lái)實(shí)現(xiàn)一個(gè)版本準(zhǔn)備線。該標(biāo)簽將手動(dòng)地生成 —— 或者更可能自動(dòng)化地 —— 作為集成構(gòu)建的一部分。

　　敏捷項(xiàng)目不但提供簡(jiǎn)化的分支策略，它還傾向于配置 ClearCase 默認(rèn)為“無(wú)限制的”檢出模型。這允許開(kāi)發(fā)人員檢出和檢入一個(gè)活動(dòng)開(kāi)發(fā)線上任意點(diǎn)上的文件（雖然如果在此期間另一個(gè)開(kāi)發(fā)人員也檢出和檢入同樣的文件，應(yīng)該對(duì)這些進(jìn)行一些合并）。默認(rèn)的 ClearCase 模型對(duì)于第一次的檢出是“受限制的”。這意味著，您不需要必須合并而保證能夠?qū)⒃貦z入回去。然而，這還意味著，其他人不能檢出受限制的元素，直到您將其放回為止，檢出無(wú)限制元素的人必須等待在合并之前您將該元素檢入回去。這種方法真的違反敏捷原則。

　　使用快照視圖開(kāi)發(fā)人員工作區(qū)。如果開(kāi)發(fā)人員將要致力于單一的分支，那么不用選擇動(dòng)態(tài)的視圖。動(dòng)態(tài)視圖的能力在于當(dāng)它們監(jiān)測(cè)的分支更新時(shí)，它們可以自動(dòng)地更新自己。因此，如果許多開(kāi)發(fā)人員在單個(gè)的分支上加上動(dòng)態(tài)的視圖，那么在它們的工作區(qū)中幾乎不能控制或隔離。雖然開(kāi)發(fā)人員分支不能實(shí)現(xiàn)，如我們已經(jīng)討論過(guò)的，但這可以導(dǎo)致其他的問(wèn)題。因此敏捷項(xiàng)目會(huì)實(shí)現(xiàn)快照視圖，從中開(kāi)發(fā)人員可以更新他們的工作區(qū)來(lái)從其他開(kāi)發(fā)人員那里引入變更。在實(shí)踐中，這給予開(kāi)發(fā)人員足夠的控制和隔離。

　　自動(dòng)化構(gòu)建過(guò)程。單個(gè)的分支開(kāi)發(fā)和增量的的檢入只有在頻繁地執(zhí)行自動(dòng)化的構(gòu)建和測(cè)試時(shí)才能夠?qū)嵭?。大多?shù)敏捷項(xiàng)目將它們的構(gòu)建過(guò)程配置為在每個(gè)開(kāi)發(fā)人人員的檢入之上執(zhí)行。除了編譯代碼，這種構(gòu)建過(guò)程還驗(yàn)證新的代碼，用以觀察代碼是否符合預(yù)定義的編碼習(xí)慣，并且在必要處執(zhí)行單元測(cè)試。在敏捷開(kāi)發(fā)方法中，該實(shí)踐常稱為持續(xù)集成。其預(yù)期的結(jié)果是為了盡早地暴露集成問(wèn)題，以便容易地處理，以及在項(xiàng)目的每個(gè)階段都有建立好的、測(cè)試了的，以及可能的可發(fā)布的構(gòu)建。持續(xù)集成常常與測(cè)試驅(qū)動(dòng)的開(kāi)發(fā)實(shí)踐雜亂的鏈接在一起。這是因?yàn)殚_(kāi)發(fā)人員需要對(duì)其代碼的所有方面實(shí)現(xiàn)單元測(cè)試來(lái)驗(yàn)證構(gòu)建已經(jīng)編譯了，以及符合最低水平的功能質(zhì)量。在 ClearCase 術(shù)語(yǔ)中，敏捷項(xiàng)目構(gòu)建過(guò)程用于監(jiān)控集成分支（或 UCM 流）以及在檢入時(shí)執(zhí)行構(gòu)建教本。這由構(gòu)建執(zhí)行工具，例如 CruiseControl（http://cruisecontrol.sourceforge.net）或 IBM Rational BuildForge（http://www.ibm.com/software/rational/buildmanagement/）來(lái)實(shí)行。

　　執(zhí)行并再利用預(yù)構(gòu)建好的二進(jìn)制碼。構(gòu)建任何相當(dāng)復(fù)雜的軟件應(yīng)用程序都會(huì)花費(fèi)時(shí)間，從幾分鐘到幾小時(shí)。在敏捷項(xiàng)目中，開(kāi)發(fā)人員將會(huì)經(jīng)常交付并集成小的變更，因此很顯然他們不可能在得到反饋之前等待兩小時(shí)完成構(gòu)建操作。為了避免這種情況，敏捷項(xiàng)目“執(zhí)行”并再利用預(yù)構(gòu)建好的二進(jìn)制碼，并且只有再必要時(shí)重新構(gòu)建整個(gè)系統(tǒng)（例如，每夜或每周）。有許多方式來(lái)執(zhí)行二進(jìn)制碼。ClearCase 常常用于執(zhí)行二進(jìn)制碼，標(biāo)簽或基線設(shè)置在相關(guān)的版本之下，來(lái)指示可復(fù)用的二進(jìn)制碼的復(fù)合集。對(duì)于 C/C++ 項(xiàng)目，ClearCase clearmake 實(shí)用程序也擁有一個(gè)避免構(gòu)建的機(jī)制，可以用于將大部分這種執(zhí)行自動(dòng)化并再利用過(guò)程，雖然沒(méi)有證據(jù)證明敏捷項(xiàng)目使用此機(jī)制。對(duì)于 Java 項(xiàng)目，另一種方法是，在相關(guān)管理工具，例如 Ivy（http://jayasoft.org/ivy）或 Maven（http://maven.apache.org）中執(zhí)行預(yù)構(gòu)建好的庫(kù)。當(dāng)項(xiàng)目再利用大量開(kāi)源組件時(shí)，或在傳遞相關(guān)性方面存在問(wèn)題時(shí)（也就是，庫(kù)依賴于其他的庫(kù)）這一點(diǎn)尤為適當(dāng)。

　　作為復(fù)合的應(yīng)用程序而發(fā)布。當(dāng)說(shuō)到發(fā)布應(yīng)用程序時(shí)，試圖發(fā)布所有的文件，而不是發(fā)布個(gè)別集合。大多數(shù)敏捷項(xiàng)目更喜歡每次部署全部的或復(fù)合的應(yīng)用程序，而不是只部署已經(jīng)變更的個(gè)別的文件。雖然這不是硬性規(guī)定，每次以同樣的方式發(fā)布全部的應(yīng)用程序趨向于使過(guò)程更加可重復(fù)并且防止文件丟失所導(dǎo)致的問(wèn)題。該實(shí)踐對(duì)敏捷項(xiàng)目比對(duì)高要求形式的項(xiàng)目更為重要，因?yàn)樗鼈冊(cè)诿看蔚笊煽蓤?zhí)行的、可測(cè)試的，并且可發(fā)布的應(yīng)用程序。很明顯，這依賴于應(yīng)用程序的目標(biāo)環(huán)境。如果是 Web 門戶，那么該方法很好，但如果是一個(gè)消費(fèi)者應(yīng)用程序（運(yùn)行在，比方說(shuō)，Microsoft Windows 上），那么完整的版本不可能每次都給客戶，所以就需要每次一個(gè)補(bǔ)丁。

　　限制 MultiSite 技術(shù)的使用。分布式的敏捷項(xiàng)目需要無(wú)限制的對(duì)單個(gè)代碼行的訪問(wèn)。ClearCase MultiSite 技術(shù)從站點(diǎn)到站點(diǎn)復(fù)制完整的數(shù)據(jù)庫(kù)。為了避免每個(gè)站點(diǎn)所做出的變更的沖突，其實(shí)現(xiàn)了一個(gè)所謂 mastership（主權(quán)） 的概念。這意味著如果一個(gè)項(xiàng)目在多個(gè)站點(diǎn)上開(kāi)發(fā)，并且開(kāi)發(fā)人員正共用同一個(gè)分支，那么每個(gè)開(kāi)發(fā)人員在提交變更之前要請(qǐng)求主權(quán)。有許多方法來(lái)處理這件事（包括創(chuàng)建基于站點(diǎn)的集成分支），但它們都增加了額外層次的復(fù)雜度，并且會(huì)減慢開(kāi)發(fā)過(guò)程。出于這些原因，敏捷項(xiàng)目?jī)A向于避免 MultiSite 技術(shù)。這就是為什么開(kāi)發(fā)了 ClearCase Remote Client (CCRC) 技術(shù)，它允許基于脫離單個(gè)服務(wù)器的分布式開(kāi)發(fā)。CCRC 的第一個(gè)版本限制了功能，然而，從版本 7.0 開(kāi)始，它將對(duì)大多數(shù)分布式項(xiàng)目提供足夠的功能。因此它應(yīng)該成為進(jìn)行分布式靈活項(xiàng)目的推薦方法。圖 3 中的屏幕快照說(shuō)明了工作于 Eclipse 環(huán)境中的 ClearCase Remote Client。

　　　　

　　　　　　　　圖 3：工作于 Eclipse 環(huán)境中的 ClearCase Remote Client

避免 ClearQuest 變更控制的過(guò)度自定義。

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

適合于敏捷方法的過(guò)程

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

　　沒(méi)有理由說(shuō)企業(yè)級(jí) SCM 工具集，例如 IBM Rational 工具集，不能用于支持敏捷開(kāi)發(fā)方法的實(shí)現(xiàn)。關(guān)鍵是，定義并實(shí)現(xiàn)一個(gè)著重于支持，而不是限制，敏捷團(tuán)隊(duì)的敏捷 SCM 過(guò)程。對(duì)于這樣的團(tuán)隊(duì)，找到正確的管理模型會(huì)是一個(gè)棘手的訓(xùn)練，但是一般建議從更開(kāi)放的過(guò)程開(kāi)始，只在必要時(shí)實(shí)現(xiàn)限制。反饋也是敏捷開(kāi)發(fā)方法的必要部分。SCM 可以有助于此反饋機(jī)制的一種方式是通過(guò)自動(dòng)化的構(gòu)建和測(cè)試（及部署）過(guò)程。因此推薦您投入大量時(shí)間關(guān)注您整個(gè)過(guò)程中的這個(gè)方面。

注釋：

1 要了解敏捷和傳統(tǒng)的開(kāi)發(fā)方法相對(duì)比的優(yōu)缺點(diǎn)和成功方面的討論，請(qǐng)參見(jiàn) Barry Boehm 和 Richard Turner 的優(yōu)秀書籍，Balancing Agility and Discipline: A Guide for the Perplexed: Addison Wesley 2004 年。另外，要了解關(guān)于敏捷開(kāi)發(fā)方法的最新討論和案例研究，您可以訪問(wèn)并訂閱The Agile Journal（http://www.agilejournal.com）。

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

3 參見(jiàn) Appleton，1998 年，Op. cit。

4 要了解更多關(guān)于如何為敏捷項(xiàng)目設(shè)立自動(dòng)化的構(gòu)建環(huán)境的信息，請(qǐng)參見(jiàn) Kevin A. Lee，IBM Rational ClearCase, Ant and CruiseControl。The Java Developers Guide to Accelerating and Automating the build process。 Addison Wesley 2006 年。