大型組織的敏捷配置管理

本文來自於 Rational Edge：由於其規模及複雜性，大企業更需要擁抱敏捷開發策略。通過本文了解如何通過敏捷配置管理環境來有效地協調成百上千的資源。

 在我作為顧問的早期，很幸運我有機會接觸一個使用了被稱為極限程式設計（eXtreme Programming）方法的專案。這個專案的環境十分典型：二十個人，有限的複雜度與平臺需求。最後這個專案成功了。新方法幫助我們按時交付並且降低了缺陷。之後，我又經歷了各種更具挑戰性的敏捷環境，包括很大的專案團隊（一百多人）和固定的成本花銷。一種最普遍的方案就是他們全部是單一的專案團隊，即使有些團隊的規模很大。儘管具備了這些經驗，我仍然不滿意于敏捷開發為企業帶來的好處 -- 尤其是關於配置管理的敏捷實踐和技術 -- 直到我在兩年時間內與財富 100 企業的專案團隊一起工作後才發生了改變。

當我作為一名顧問進入到公司後，我發現這是一家不使用常規原始碼控制、只有少量自動化構建或自動化單元測試的企業。我們花費了幾個月的時間，利用持續的整合、短迭代、和各種其他的敏捷實踐與技術，最終建立了一個更靈活的專案團隊。當專案成功後，團隊成員就可以幫助其他團隊使用敏捷方法了。十八個月後，我們已經有了六個遵循主要敏捷配置管理實踐的專案。每個專案團隊具備自己的程式碼庫，但是他們會互相共享元件、測試和構建流程。程式設計師會在一天內多次檢入程式碼，儘快地增加自動測試，甚至寫了幾行程式碼後就會重新編譯。專案團隊會在一天內多次執行他們自己的自動化測試元件和系統。企業開始從更健壯的程式碼庫、更及時的交付、和更好的最終產品中獲益。

從那時起，許多大公司的開發團隊都希望瞭解敏捷是否適合他們。他們一直認為敏捷是無序的、混亂的，並且風險很大。沒有什麼比事實更有說服力了。我自己的經驗證明了敏捷實踐和技術能夠提供可靠的靈活的配置管理環境，而這正符合了大公司保持競爭力，滿足質量的目標。

我將在本文中展示部分基本的敏捷配置管理構建模組，並詳細介紹如何使用這些實踐為大型開發企業帶來收益。

開始之前：術語宣告

術語對於專業的軟體開發來說既有益處又有壞處。也就是說，我們都利用術語來工作。不幸的是，我們往往使用它們的意思而使工作做得很糟糕。因此，在繼續之前，我想首先花一些時間宣告一下我將使用的術語。

由最先出現的開始 大型開發組織 可以有很多種形式。例如，它可以是一個大型專案，包括了上百人，為了計劃和開發的目的分解為許多個子系統和子團隊。它還可以是一家開發企業，包括許多相互聯絡的系統和專案團隊。更一般的說法是，它可以是任何被描述為 "企業"的開發組織。 大的開發組織意味著多個團隊和大量程式碼行。這些大型組織常常擁有不同階段的開發、產品，或接近退役的系統；任意的資料庫、檔案倉庫和其他的資料來源；一系列不同的專案方案和委託；含有各種需求和議程的一群有趣的團隊。這些大型組織常常接近（或已經陷於)複雜性之中。

更高水平的， 敏捷開發 很容易定義。它描述了任意的堅持敏捷軟體開發的宣稱價值的開發方法（尤其是偽裝成專案團隊熟知的方法論）。 ¹ 簡短來說，這些值關注於個人和互動、工作軟體和使用者協作，它們承認改變是不可避免的甚至是有價值的軟體開發部分。但是這一高階定義僅描述了敏捷團隊的價值，而沒有他們所做的內容。當我談論敏捷所做的內容時，我是指敏捷團隊尊循的實踐和技術，諸如持續整合、自動化的單元測試和短疊代。敏捷社群中不斷討論著遵循敏捷實踐卻不使用敏捷值的團隊是否能夠被稱為敏捷的。這些值是十分重要的，因為它們提供了適當的 Agie 實踐和技術的實現指導。但是，我將會跨過這些爭論，使用術語敏捷以鑑別敏捷團隊使用的實踐和技術。

然後， 配置管理 -- 可被描述為 "質量"的概念 -- 傳統意義上具有多種不同定義。 ² 大家似乎完全同意配置管理包括了鑑別系統條目和特定條目與系統的變化。一種狹義的配置管理的定義可以滿足流行原始碼控制系統的實現及使用。同時， 一種廣義的定義也許涵蓋了全部專案團隊和所有工件，包括全部的確保系統正確操作的程式碼和行為，所有改變控制元件行為，和追蹤團隊每天的變化。我將在本文中對配置管理採用一種中立的定義，包括了程式設計師所做的組織系統元件，瞭解任意時刻的系統狀態、管理演化、確保開發過程中正確的系統功能。

大企業對敏捷實踐的需求

現在我們已經符合了討論的標準，讓我們看看它們是如何在一起工作的。首先，小型專案沒有了質量不一和不正規的配置管理實踐時，大部分讀者可能都會同意大型開發組織都會需要正規的配置管理方法。這種認識在六年前被認為是十分大膽的，而我根據針對大型開發遇到的問題所做的觀察得出的這一結論。當幾十種（沒有上百）產品元件正在執行，並且您與上百個（沒有上千）開發者協作時，潛在的混亂、遲緩的開發週期、和很差產品質量的可能性是十分高的。大型系統變得過於複雜與迅速以至於不能靠手動系統加以維護了。因此在這些企業中，自動化、流程控制、管理變化、和團隊協調對於保證開發質量是十分必要的。

其次，讓我們討論一下敏捷開發和配置管理的混合。當敏捷開發還是一種新興的，軟體開發專家最為重視的破壞進度、開銷溢位、專案失敗特點的主題時，沒有人談論配置管理的敏捷方法。但是敏捷證明了它是一種極好的配置管理實踐，因為敏捷團隊需要健壯的靈活的程式碼庫以響應不斷變化的業務環境和客戶需求。一種方式是在專案中經常性的整合程式碼（一般來所，一天整合幾次）。另一種敏捷的重要原則就是將測試作為一種有效的配置管理元件。在許多敏捷團隊中，全部新程式碼都要經過自動化的單元測試，每次執行架構都會執行所有單元測試。未通過的單元測試將被視為與編譯錯誤一樣嚴重的問題。在任何好的配置管理流程中，敏捷團隊都需要了解所有程式碼行的健康度。而且，他們努力保持對程式碼狀態的控制。

最後，就是敏捷開發和大型開發組織。所有的大企業確實可從整合的敏捷開發部分獲得收益。理所當然,有獨特的大型開發組織的挑戰，例如，與多個專案、系統、資料來源連線的邏輯行為外的個人與團隊間的通訊與協作。但是無論是否遵循敏捷方法，大型組織都有其需要面對的問題。

敏捷開發能為大型企業提供什麼？首先，敏捷能夠通過自動化的實現任務以減少人類所犯錯誤並使得團隊利用更少的資源作更多工作以提高團隊效率。其次，敏捷能夠幫助大型企業改進質量，更有效的處理回饋給開發成員的改變，從而更迅速的解決問題。第三，敏捷能夠通過使用疊代計劃、分析、開發行為 -- 這些可由系統根據所設計的程式碼自動化的產生 -- 替換龐大的（且很快過期的）需求文件，以進行更豐富更及時地溝通。

最後，敏捷配置管理方法可以在專案級或企業級加以實現。不需要在這之前考慮一個組織，因為單個專案可以是一種實驗性的或想法孵化器。同時，當在企業級實現了敏捷配置管理實踐，那麼企業必須為每個專案團隊提供足夠的靈活性與自主性，實現其最佳解決方案。

敏捷配置管理實踐

精簡程式和自動化是敏捷配置管理方法的基礎。 ³ 每一個活動（來自於程式碼檢測確定損壞測試）都應很容易的執行，併為單個程式設計師和整體團隊提供快速反饋。而且，敏捷團隊力圖使得這一行為自動化的記錄於文件中。例如，自動化的構建僅需要寫入它的執行指令碼中。可以很容易的得出包括由 Microsoft Word 所建立的過期文件，"指南"文件在內的良好自動化構建指令碼收集的好處。

已根據各種專案環境中的用途標識出了組成敏捷配置管理的實踐 -- 無論大或小，簡單或複雜。 我將在本部分中探討實踐，下一部分討論針對大型企業特殊需求的應用。

原始碼控制

這是常常會忘記的重要敏捷配置管理的元件，並不是因為組成敏捷團隊不使用原始碼控制。它常常被忘記是因為大部分敏捷團隊假定每個專案都會有一個原始碼控制系統，並且每個專案都會正確的使用它。一般的原始碼控制系統都會有許多部分，例如版本化、回滾、打標籤以及合併等。但是更重要的是，原始碼控制為全部專案團隊或開發組織的程式碼行提供了可靠的記錄位置 。這僅僅當每名程式設計師能夠經常性的檢入系統程式碼時才會發生。我的意思是至少一天一次。這時，專案能夠了解在哪裡找到當前系統。它不會由於不同的開發工作站，或位於不同地點的共享伺服器造成支離破碎。當前系統（或僅僅幾小時前）總是檢查原始碼控制系統。

重申一下，僅僅因為專案或組織具有原始碼控制系統不意味著系統支援敏捷配置管理方法。在我管理幾個團隊的客戶端，兩百名員工的開發組織使用企業級的原始碼控制授權工具。但是系統卻有重大的瑕疵：執行一次 check-in 要花費數小時！因此，團隊僅僅在不得已的時候才做一次 check in -- 在釋出到產品環境之前。一種普通的原始碼控制系統對於一家大型企業十分有益（之後會做解釋），但是僅僅限於程式設計師和團隊能夠以具有時效的方式檢入/檢出程式碼的情況。

我將對原始碼控制作最後的解釋。團隊不應該僅僅對所寫程式碼進行版本控制；還必須對編譯與測試程式碼的流程（或指令碼）進行版本控制。如果團隊需要先前的程式碼，那麼就可以回溯到所需的構建和測試流程。

構建自動化

自動化構建是團隊用以評估當前軟體或系統穩定性的第一步。而且，自動化的構建還可以降低程式花費在不必要任務上的時間，並且減少了來自開發流程的瓶頸（也就是，團隊依靠於一個構建人員或一個獨立的構建團隊），從而實現了對於改變的更迅速的響應。

這一實踐的目的是將構建流程簡化為一個任何程式設計師都可以執行的點選一個按鈕的 行為。這一行為應該包括相關係統的全部程式碼，不論程式設計師工作於什麼元件或介面上。同時，系統必須能夠快速編譯。更快的工作站、增加的編輯和可選擇的編譯器可以使得編譯時間更加短暫。對於程式設計師來說，寫新程式碼的同時快速構建系統的能力具有許多好處。首先，它幫助程式設計師驗證編碼時設想的正確性 -- 例如，檢驗一個外部 API 是否如設想似的工作。其次，規則化的程式碼構建可以預防問題的發生。最後，它能夠識別未知的很少通過本地構建顯現的"遠離"系統部分依賴關係。

自動化的構建將會減少團隊編輯和收集問題的時間。程式設計師不再需要等待數小時或者執行一組費勁的任務以確信新寫的程式碼能夠編譯。取而代之的是，在程式設計師編寫程式碼後不久，他就能夠知道是否新程式碼與舊有程式碼整合到了一起。這表示編譯與整合錯誤將會變得顯而易見，且處理起來更迅速更容易。

最後，自動化的構建對於更大系統更加重要。 大專案會繼承或連線大量其它平臺的系統，尤其是需要考慮有意義的聯合構建流程的實際策略。在這種環境中要想獲得較短的編譯時間是極具挑戰性的。文章的後面我將會探討一些處理大系統構建的方法 -- 就是說，對於一個團隊來說，編譯與測試完整的系統並不是現實的。

自動的移植及部署

這是在自動構建之後的步驟。自動化的移植與部署行為的原因是為了精簡與增強來自測試環境開發與生產環境的構建提升的可預見性。大量的問題往往來自首次引入系統測試、使用者驗收測試、在生產環境摸索的專案。在自動化移植中，團隊可以將程式碼轉入乾淨的"生產級" 環境，在那裡可以執行自動化的單元和系統級測試。通過在接近生產環境下測試，團隊可以在系統測試前識別出環境、整合和效能方面的問題。這樣可使得團隊更加熟悉實際的產品部署流程。最後，當自動化的實現了主要的產品部署流程時，就可以從公式中去除了人所犯的錯誤。

另一個移植與部署的重點是這些行為由一個專職團隊負責管理。將這些流程整合入專案團對每日的行為中能夠為各個團隊帶來有效及時地平衡。無可否認的是，對於大型企業來說這是極具挑戰性的，因為他們的規模、報告結構和多重地理範圍的因素。下面我將會更深入的探討這一問題的解決方案。

測試自動化

自動化的測試是瞭解當前系統是否達到準備釋出狀態的第一步。自動化測試應伴隨系統中的全部新程式碼。除此之外，當老的、未測試的程式碼被改變的時候，程式設計師應為程式碼編寫新的測試。最後，當在驗收測試或產品中發現缺陷時，應記錄這一測試以證明缺陷，並且這一新測試應加入到全部測試集合中以避免今後發生相同的問題。當系統中所有的單元測試全部通過後，程式設計師應當對其程式碼有信心，相信不會影響系統的其他部分。

從敏捷的觀點來看，自動化的單元級測試是構建流程的擴充套件。程式設計師每次執行構建流程併成功編譯程式碼時，應遵循所有的應用單元測試。在敏捷配置管理環境中，損壞的單元測試與損壞的構建嚴重程度是一樣的。這樣小問題就不會擴充套件為大問題了。大問題（諸如全部程式停止工作）不會隱藏在後臺。取而代之的是，團隊可以在問題發生時定位，不斷增長的單元測試集增加了準確監測錯誤的可能性。

我要補充一點關於單元級和系統級測試的內容：明智的專案和企業會進行 測試資料管理。這樣就使得測試資料很容易的建立、修改、維護（當系統資料結構發展變化時）、儲存（在每次測試前）。當資料模型發生大的變化時，甚至是在某些情況下，當開發資料庫被清理掉時，依賴於脆弱的以及被隨意修改的資料結構的大量自動化測試集就可以得到迅速的調整。

持續整合

持續整合與原始碼控制、自動化構建流程、值得信賴的自動化測試集共同保證了開發過程中系統的穩定性和系統效能。在持續整合的環境中，程式設計師需要編寫程式碼，在工作站上執行構建和測試，一天內多次進行檢入。同時，有一臺構建機（或一組機器）用以編譯整個系統，在類似於產品配置的乾淨的環境中執行所有測試。這種行為可通過手動或者自動的方式啟動 -- 或者間隔固定的時間或者由程式設計師檢查程式碼。當程式碼沒有在乾淨的環境中通過構建和測試時，無論什麼原因，都會在檢查後提醒全體成員。大部分情況下，敏捷團隊都不會允許任何人檢入額外的程式碼，直到解決了問題。

持續整合帶來的好處是，它灌輸了一種開發原則，不鼓勵檢入低質量的程式碼，且當問題發生時需要立刻解決。由於每天要進行多次程式碼檢入 ，處於整合環境中的程式設計師很少或從不改變引起不穩定構建的程式碼。除此之外，如果遇到未完成的程式碼，團隊的構建機制能夠在幾小時內記錄它，而不是幾天或幾周。因此，程式設計師在中斷程式碼前，不得不仔細考慮整體設計，甚至需要進行一些測試。這意味著處於持續整合環境中的程式設計師很少會在系統程式碼中直接進行試驗，很少出現寫了一半卻忘記完成的函式，或是將系統元件遺忘在某處。當編寫程式碼後立即監測出錯誤，解決問題所花費的時間往往少於幾天或幾周後才發現時所花費的時間。 這樣，就保證了高質量的程式碼和更加迅速的發行週期。

對於大系統的可擴充套件的敏捷配置管理

大型企業經歷過許多類似中小型專案遇到過的 CM 問題，還有部分附加的多系統、多專案、多初始屬性的問題。例如，當小專案未監測出一個缺陷或者遇到了需要花費幾個小時甚至幾天才能解決的整合問題時，對於大型企業來說也許會花費幾周的時間才能解決。相似的還有，對於小專案的原始碼控制和版本的問題相比較於大型企業沒有可依賴的配置管理系統時所遇到的系統回滾或多應用重新部署問題來說，簡直是微不足道的。依據其規模與複雜度來說，適當的配置管理實踐對於大企業是十分必要的。

配置管理的敏捷方法能夠幫助大企業定位配置管理問題，同時保持對客戶需求變化、進化的業務環境、不斷提高的技術的靈活性。除此之外，敏捷配置管理方法還能夠幫助新專案重複使用現有系統與專案的構建流程加快構建與執行的腳步。

本部分中，我們將會探討在大型開發組織中使用敏捷實踐的三個主題。第一，我們將探討如何靈活的執行敏捷的 CM 流程為單個專案團隊和大型開發組織帶來好處。第二，如何在地點分散的企業中的分散式專案上使用敏捷配置管理方法。最後，企業如何通過深思熟慮的應用與流程整合加速軟體交付週期，增強規模經濟。

有效的團隊協調：共享程式碼庫和鏈式構建

每天的專案環境中往往需要團隊間共享程式碼，使用通用庫，甚至共享一個又一個的構建流程。例如，一個專案也許需要包含其它專案的構建與測試行為。這可能包括獲得共享庫的更新版本以確保其它專案的改變不會影響團隊的程式碼，或是保證團隊程式碼庫德變化不會影響另一個專案程式碼的功能。而且，專案間可以共享隨時更新的核心資源。這種資源可以包括通用類或類似於測試工具與測試資料生成器等。這種情況在大型企業中十分普遍，它們會自然而然的形成，不需要企業自身的協調。

敏捷方法為開發團隊提供了更有效合作、實時通訊以保證專案進展的機會。通過提供構建成功/失敗的快速反饋，開發者能夠在最恰當的時候檢測與解決問題。

為了在大型開發組織中更加有效，敏捷實踐必須在單個團隊級別上實現，但是應由企業級配置管理最佳實踐支援。當執行企業級敏捷配置管理方法時，團隊必須負責起多項任務。第一，必須允許基於實踐的可靠的敏捷配置管理執行。第二，必須使得流程對於其他團隊可見。第三，適當的時候必須包括自身構建與測試行為的系統構建流程。最後一步不需要程式設計師在每天的工作中完成，但它必須由一個自動化流程儘可能多的執行（理想情況下，從一天一次到一週一次之間）。當其他系統出現問題時，必須快速解決。

為幫助所有團隊執行敏捷配置管理， CM 組織還將負有不同的責任。這些任務屬於共享的服務實體（常常被稱為 Engineering Services Groups)。這種企業會提供一個通用的、使用者友好的工具集獲平臺，所有團隊可通過它們完成與共享原始碼控制、構建、和測試行為。這種平臺包括諸如原始碼控制、構建、和測試系統的元件。而且，企業應在 敏捷配置管理實踐的執行中提供支援與引導，提供一組可重複使用的 CM 流程或最佳實踐推薦以實現一致性和可靠性。最後，企業必須確保每個團隊必須具有足夠的 CM 流程控制的能力。這看起來有點像在搞平衡，但是對於有效的軟體交付來說是有必要的。最終，仍然是團隊構建軟體，企業的工作是幫助每個專案獲得最大的成功。

支援分散式團隊和組織

許多敏捷方法論確實沒有考慮分散式團隊的情況，但是這一大企業中的普遍特徵不會被希望改變軟體開發產業的進步所忽視。儘管缺乏具體的關注，但是敏捷配置管理方法仍然對於具有分散式團隊環境的專案和企業來說十分有效。

為了從敏捷配置管理方法中獲益，分散式的專案和企業必須平衡部分敏捷配置管理實踐的固定實現，尤其是固定的原始碼控制使用、持續整合、和自動化測試。我們不能誇大經常檢入和穩定構建維護的重要性，因為被時區或地理位置分開的團隊成員需要訪問完成的可操作的系統版本。當某些部分損壞或過期後，沒有其他位置的團隊成員可以幫你一把。

為了給分散式專案維護敏捷配置管理解決方案，必須檢查原始碼控制，包括構建指令碼和本地環境設定。在任何一個位置的改變都必須自動複製到其他的開發場所。這是因為分散式團隊協作和大系統的複雜性決定的。一旦開發過程中系統僅在一處開始出現離奇的行為時，也許需要花費很長時間才能找到問題的根源，而這一問題僅僅是因為沒人會想到引起如此問題的伺服器或虛擬機器的設定。

除此之外，與資料庫相關的所有部分都需要被複制與共享。這可以通過定製所有資料庫的改變和檢驗原始碼控制實現。 ⁴ 它還可以通過某種資料庫複製的形式實現。最後，專案必須解決連線或開發行為必須執行的第三方系統的問題。每處場所都必須具有訪問相同系統的能力。

有兩種普遍的實現分散式和敏捷配置管理環境的方法。第一種就是建立一個單一的開發環境，它可被所有開發團隊連續訪問。這種環境包括 -- 至少 -- 單一的原始碼控制系統，全部資料庫和連線系統，執行持續整合的能力。這種解決方案適合於工作在臨近時區且具有可靠網路訪問能力的團隊。第二種方法是構建概念上的單機開發站點。每個團隊具有一個完整獨立且相同的開發環境，包括源控制元件，資料庫，附加的系統安裝，和持續整合安裝。每天的複製計劃必須保證所有站點的程式碼，資料，和環境的同步改變。同步行為必須儘可能的自動化。而且，自動化測試必須有規律的編寫與執行。如果沒有執行每天的複製和完整測試（就是說，如果沒有同步化操作），企業也許不久會發現自身處於夢魘中。最後，專案和企業可以使用中立的解決方案，即部分敏捷配置管理環境集中實現，而剩餘部分由各個站點單獨實現。例如，企業具有通用的原始碼控制和構建系統，但是在不同開發場所維護本地資料庫實踐和其他第三方系統。

通過靈活的工具與流程整合的可擴充套件性

如果在建立良好構建流程和自動化前進行了充分的考慮與準備，那麼它會成為十分有用的開發資產，這些設施能夠（應該）在多個專案間做到平衡。大企業的低效源自於為每個軟體專案建立一個新的構建系統。結果是以專門的硬體資源和配置管理人員支援多個定製的構建程式。這樣就使得大型企業不能根據規模效益從資源池、人員和最佳實踐知識中獲益。

如果企業計劃在任意規模實現敏捷實踐（意味著在多個團隊、專案和/或操作平臺上同時進行 編碼-構建-測試-部署週期），那麼應當仔細思考這些系統如何通訊、互動以建立平滑的編碼-構建-測試-部署週期。如果跨團隊的，跨系統的整合不是全部開發策略的因素，那麼團隊常常會發現隔閡，等待週期，和函式間的錯誤通訊會造成開發進度的遲緩。如果沒有追蹤和收集每個階段資訊的設施，那麼團隊很難確定系統真實的健康度和釋出狀態。

整合應包括來自核心開發系統的工作流自動化和資訊共享（或者至少是抽取）。工作流自動化包括包括任務的次序與安排，並且應包括基於規則的改變任務執行與前步成功或失敗告知的能力。當決定您的整合方法時，團隊應考慮產業標準方法(XML，等)以構建適應需求改變和開發應用的靈活的解決方案。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12231076/viewspace-194/，如需轉載，請註明出處，否則將追究法律責任。