持續交付成熟度模型的解析和理解
持續交付的原則和方法，正在迅速地被越來越多的人認可為一種真正的業務敏捷的成功策略。對于許多組織結構，問題不再是“為什么要采用”，而是“如何采用”：持續交付如何起步，以及組織機構應該進行哪些調整，才能保證得到可以接受的成果。本文介紹的這個成熟度模型，目的在于給出一個框架以及對幾個關鍵方面的理解，這些方面是你在組織中采用持續交付時需要重點考慮的。
為什么要有這個成熟度模型？
持續交付的中心思想就在于著眼全局，去考慮影響軟件開發和發布的方方面面。不幸的是，對于任何正常規模的，比較重要的業務，這些影響因素都會包括相當多的步驟和活動。從軟件開發到發布的端到端過程往往冗長而笨重，牽扯到許許多多的員工、部門和障礙，使得持續交付的實現看起來力不從心。我們從哪里開始呢？我們是不是什么 都要做，有哪些部分可以省略？在哪些部分我們能得到最顯著、最快速的效果？這些都是在你開始接觸持續交付的實現時，不可避免會出現的問題。
這就是我們為什么要創造持續交付成熟度模型，給出結構和理解持續交付及其核心部件的實現。這種模型的靈感主要來源于我們在幾個持續交付實施項目中結合起來的經驗，也來自于根據這個主題選定的書籍，論文和博客文章，其中 Jez Humble 和 David Farley 的開創性著作持續交付（http://www.amazon.com/dp/0321601912?tag=contindelive-20）和Eric Minick 與 Jeffrey Fredricks了不起的白皮書 企業持續交付模型（http://www.urbancode.com/html/resources/white-papers/Enterprise_Continuous_Delivery_Maturity_Model/） 是值得特別表揚的兩個。有了這個模型，我們的目標更廣泛了，擴展出超越自動化的概念，突顯了你要在整個組織之間成功實施持續交付所需考慮的所有關鍵方面。
一種結構化的嘗試
敏捷開發這場十年前開始的旅程，到今天終于在工業界站穩了腳跟。現在的業務***開始逐漸接受這個事實：軟件開發有“敏捷”這么一種新的思考方式。這種思考模式的轉移，如果你不介意這么叫的話，最終會不可避免地將工業界分裂為兩派：一派在競爭中艱難掙扎，另一派則有能力保持敏捷，IT 組織反應快速而高效，能提供可靠的業務保證，從而在競爭中立于不敗之地。在昂貴、緩慢、不可預知而過時的流程面前，IT 再次推動了革新。進入這個新領域的方法有很多，在此我們主要介紹一種結構化的嘗試，以期獲得***的結果。盡管敏捷方法一般被認為***從組織內部成長起來，我們發現這種嘗試仍有局限性。組織的某些部門還不夠成熟，無法適應和調整，因此阻礙了開發，形成了頑固不化的組織邊界。要想讓整個組織一起改變，***方法是建立一個穩固的平臺，這個平臺需要具有一些重要的先決條件，確保組織向正確的方向發展。平臺需要采用特定的工具、原則、方法和實踐方式，我們歸為關鍵的5類：文化與體制，設計與架構，構建與部署，測試與證明，信息與報告。將持續交付模型根據自然的推進過程結構化為這5類，可以給你提供一個堅實的基礎，來進行快速的改革并獲得可接受的成果。
創建成熟度模型是為了強調這五個基本類別，并讓你掌握公司的成熟度。當計劃持續交付實現時，你的評估講給你提供很好的基準并幫助你確定最快、***效率的初步行動。這個模塊會指明哪個實踐必不可少，哪個應該歸位高級或者專家級的以及從一個基本遷移到下一個需要什么條件。
五個級別
這個模型定義了五個成熟度級別：基礎、初級、中級、高級和專家級。它是基于我們可見的，現在大部分機構采用的基礎級別附近的一個典型的工業平均水平為基點校準的。一些機構在某些類別達到初級，另一些（模型外）低于基礎級別，但平均來說，基礎級別是很多機構的典型起點。中級級別是指一個能讓你受益于更大影響的持續交付實踐的成熟度級別。高級級別包括那些可以產生更高實質性價值和影響的實踐。***的成熟度級別：專家級包含對某些希望或需要專注特定實踐的機構非常重要的實踐。
層級并不是需要順序通過的強制的階段，但是它們可以做為評估和計劃的基礎。無論試圖保持總體的成熟度水平公平多什么重要，一定要牢記大的變化可能會在組織里引起批評和大家的不情愿，因此推薦通過漸進的方法來推進層級的發展。
五個域（分類）
模型已經定義 了五個域（分類），這些分類代表了在實施持續的發布時需要考慮的核心的角度。每個分類都有它自身的成熟度的連續性，但是一個組織一般是逐步達到某些域（分類）的成熟度而不是只有一個或兩個域（分類），因為它們上彼此關聯，一定程度上相互影響的。
文化與組織
當目標是創建一個穩定的持續發布環境時，組織和它的文化是需要考慮的重要的角度，這個環境會受到它們的影響。
基本階段
典型的組織在基本階段，開始在后臺日志進行優化工作，定義了一些流程，這些流程進行了簡單的文檔化，開發人員習慣了經常提交版本控制。
初始階段
進入初始階段，項目團隊是穩定的，組織逐步開始移除測試之間的邊界。大量的后臺日志自然而然的合并到每個團隊，基本的敏捷方法已開始應用，相對健壯的團隊已共同體會到了糟糕的事情發生時的痛苦。
中間級
在中間級你將會收獲一個擴展性更好的團隊合作，數據庫管理員、配置管理員和運維人員開始成為團隊的一部分，或者至少團隊頻繁的與他們溝通。多個流程已經穩定，所有的變更、問題、新功能、緊急修復等都依照相同的方式進入生產環境。決策分散到項目團隊，組件的所有者已經定義了，這些使得項目團隊可以高質量的構建，可以為持續的生產和過程改進制定計劃。
高階級
在高階級，團隊有了能力和信心，它需要自始至終為產品的變更負責。持續的改進機制是適當的，例如成立了專門的工具團隊通過改進工具和自動化來為其它團隊提供服務。在這個階段，功能的發布可以與實際的布署相分離，這會給項目產生不同的角色。一個項目可以關注于一個或多個團隊的產品需求，當所有的或者相當數據的需求已被驗證并布署到生產環境，項目組應當計劃并組織針對不同用戶的實用版本。這種關注的分離優化了項目打包和發布功能的的靈活性，同時使得開發團隊更好的跟進產品，因為他們不需要累加變更，不需要因協調項目的發布而等待。
專家級
在專家級，一些組織選擇花費很大的努力形成完整的跨職能的團隊，這些完全是自發的。因為有極短的迭代周期和相當成熟的發布通道，這樣的組織有信心適應相當嚴格的從策略到產品推進的失敗率要求。
設計和架構
你的產品和服務的設計和架構將對持續發布產生至關重要的影響。如果從一開始，一個系統的構建是依照持續的發布通道，有一個快速的發布心態，那么這個過程會相當的平滑。然而，超前完成重構整個系統對于大多數組織而言并不是一個理想的選擇，這就是為什么我們要把這個分類包括到成熟度模型中的原因。
基本級
通常一個組織會有一個或者多個包含了開發、構建和發布的完整功能的遺留系統。在基本級的許多組織會有一個多樣的技術棧，但是已經開始鞏固這些技術方案和平臺，這對于從已花費在自動化上的許多努力來獲取***的價值來說是相當重要的。
開始
在開始階段，系統的單片結構就采用將系統分成模塊的方法解決的。模塊給開發、構建和部署提供了很好的結構，但是不能像元件一樣單獨的發布。做這些也將會驅動一種API的管理方式去描述內部的獨立性，也將會影響運用結構方式去管理第三方的庫。在這個階段，運用版本控制數據庫的改變的重要性也將會揭示這一點。
中間層
移動中間層將會導致固定的架構基礎。這樣做是為了當采用抽象方式的分支和其他的技術特性能夠隱藏（隱藏的目的是減小倉庫的分支，去確保真正的持續性集成）時候，能夠提供持續性的交付。這一層的工作是模塊化，它將用于鑒定和分割模塊成元件，元件是具有自我保持和分開部署的特點。在這個階段，它很自然會開始分散的遷移、特設管理應用和運行時間配置到版本控制中，將它視為像其他代碼一樣的應用中的一部分。
高級
在高級階段，你將會把整個系統分成自我保持的元件，采用嚴格的基于API的方式去完成內部的溝通。這樣每個元件都能夠被獨立的部署和發布。基于架構的成熟元件中，每個元件是一個自我保持可發布的單元，具有業務價值；你將會完成小的、高頻率的發布和整個短的發布周期。在這個層面，對于業務而言，很容易去快速的發布新的特性、監測和確認預期的業務結果；所以從應用去推動業務模塊的技術將會變得越來越重要，它將成為整個設計和架構的一部分。
專家級
在專家級，一些組織進一步引入了基于架構的組件和評估盡可能多的削減共享基礎架構的完善性，這樣就可以把基礎架構做為代碼把它與應用組件關聯起來。這將導致相對于源代碼控制、操作系統，系統完全是可以重寫的，可以直接重用到應用程序。這樣降低了工具和一些技術的復雜性和成本。例如對生產環境的災難恢復變得相當容易。不必有一個單獨的流程，災難恢復只是簡單的從通道中像抽取其它版本一樣，抽取它的上一個版本。與此同時虛擬化使得搭建測試和生產環境相當的靈活，只需要很少的人力成本。構建 & 部署
對于持續交付而言，構建和部署無疑是核心。在這個過程中，很多工具和自動化被應用進來；一旦持續交付被論及，這個過程也是最常被認知的。乍看起來，一個典型且成熟的交付方式是非常具有壓倒性優勢的；但鑒于組織中當前構建和部署的成熟程度不同，該交付方式的復雜程度或大或小。從這個層面來說，我們將描述一個有邏輯的成熟的過程，為不同的部分和環節提供結構知識來方便理解。
基礎
基本上，你將會擁有一套代碼庫，它是受版本控制的、被腳本化構建的，同時它定期運行在一個專用的構建服務器上。部署的過程是個手工或者帶有部分腳本和基本記錄的半手工過程。
初學者
初學者水平介紹了為了更快的反饋而進行頻繁的輪詢構建，為了更易于依賴關系管理而將構件存檔。標簽和版本的構建是結構化的，不過手冊和部署的過程，連同文檔、腳本和工具，正在逐漸變得更標準化。
中間級
在中間級水平上，構建通常會在源代碼控制系統的每一次提交中被觸發，即嘗試把一項細節提交到一個特定的構建中。標簽和版本的構建是自動化的，部署的過程在所有環境中是標準化的。構件或者發布包只被構建一次，且被設計成可以部署在任何環境中。標準化的部署過程還將包含一個為自動化數據庫部署（或者遷移）提供的源碼。這個源碼中包含大量的數據庫修改和腳本運行時配置的修改。一個基本的交付通道恰好涵蓋了從源碼控制到生產的各個階段。
高級
在這個階段，它也可能成為向外擴展的構建所必需的，這里說到的構建是在多臺機器上為了并行處理和特定的目標環境所進行的構建。零當機部署的技術可以是重要的，包括自動化過程中獲得更好的靈活性和在發布時降低風險和成本。在這個層次上，你可以探索那些能夠使更復雜的數據庫更改和遷移變的自動化的技術，來完全避免數據庫更新時的手工慣例。
專家級
專家級的實踐特征之一是無接觸的持續布署到產品，每條命令都可以自動化的運用到產品中。專家級實踐的另一個特點是把架構做為代碼，進一步的虛擬化，使得構造過程不僅布署了人工的部分，還完成了虛擬機，該虛擬無須停掉下層通道，直接替換現有的虛擬機。
#p#
測試與驗證
測試無須質疑對于任何一軟件開發都相當重要，它絕對是實現持續發布的至關重要的重要部分。與構造與布署類似，這個類別的成熟度包括了工具與自動化。然而，同樣重要的還有持續的增量的對應用的測試覆蓋，這構成了快速發布的可信度。通常測試包括了用不同方式依照需求驗證期待的功能，但是我們同樣需要強調驗證預期的發布的版本特征的業務價值的重要性。
基本階段
在基本階段的成熟度模型中，開發團隊或者開發組織通常會實踐單元測試，有一個或多個專用的測試環境，這些環境與本地的開發機器是分離的。這些系統和整體層測試都會由一個單獨的部門執行，在開發代碼凍結后持續的開展一個長期的、冗長的測試周期內執行。
初始階段
在進入初始階段后你將自然而然的開始研究漸近的自動化，通過自動化使現存的人工的集成測試快速的反饋，使得回歸測試更易于理解。為了精準的測試，組件必須在與產品類似的環境中布署和測試，這個環境要包括所有必需的依賴條件。
中間階段
初始階段中你把自動化測試的范圍擴大到功能測試，包括了比單元測試更大的組件，但是會使用樁來實現它的外部依賴，例如數據庫或其它后臺服務。當你在一個高度基于組件的架構中工作或者好的完整的集成測試的實施相當困難或者運行頻度太慢時，這些測試是相當有價值的。在這一階段你將可能開始把接收測試的一些部分逐步的自動化。集成測試是一些特殊的組件，接收測試是掃描大量的組件并跨越多個系統。
高級階段
高級階段的實踐包含完全自動化的驗收測試和從需求中可能直接產生結構化的驗收標準，需求的詳述是通過案例和特定領域的語言來完成的。這意味著沒有測試手冊用來測試或者驗證，驗證就是需要通過驗收，但是典型的處理還是會包含許多探索性測試。通過這種探索性測試反饋到自動化測試中，不斷地改進測試的覆蓋率和質量。如果你關聯測試的覆蓋率與更改的可回溯性，你就能實踐基于風險的測試，為指導探索性測試帶來更好的價值。在高級階段，許多機構可能會持續關注自動化的性能測試和針對安全的掃描。
專家階段
這樣的表述可能看起來很特別，驗證期待的商業結果是一個專家級的實踐過程，但是這很實在的東西。現今，一個自然而然的開發和發布過程，很少會去做這樣的一個驗證。當組織，文化和工具已經達到一個成熟的階段，驗證改變所帶來的商業價值變得更為自然而然，并且相關業務標準的反饋是高效化的和易操作的。以一個新特性的實現為例，必須包含有效的方法通過確認相關指標去驗證期待的商業結果是推進還是拉低了應用的效果。完成的定義必須被擴展到當發布的特點和更改的效果被商業分析之后。
信息和上報
任何的商業過程都包含一個特殊的可以被上報的信息集合。軟件的開發和發布過程也不例外，并且在這個領域的信息集合包含一些特定的概念包括組件，需求，版本，開發者，發布，開發環境等等。當采用持續交付模型時，我們希望在這個分類里針對重要的處理能顯示正確的信息。信息必須簡潔，切題和易于理解，還要在對的時間，對的人，為了獲得完全的速度和可能的靈活性促進持續交付。除了通過開發和發布新特性來讓信息直接被用于實現業務需求，同樣重要的是獲取信息需要測量過程的本身,并不斷改進它。
基本階段
在基本階段，在分類中最重要的是為當前的過程建立一個基礎的指標，這樣你就可以評估和跟蹤。在這個階段通常是手動去做并且需求是由個體決定。有趣的指標例如：循環周期，交付日期，發布個數，緊急修復個數，事件個數，每次發布的特性個數，集成測試期間發現的bug等等。
初級階段
在初級階段，開始衡量進度并跟蹤績效，有助于更好地了解哪里需要進一步改善，以及獲得的改善是否是期望的結果。在這個階段獲得的報表包括代碼的靜態分析，并且這個報表必須是周期性的，才能保證用***的報表來輔助決策或者發現哪里需要改進。
中級階段
到了中級階段，你必須建立一個通用的信息模型，用來標準化所有概念的含義，以及定義好它們之間的聯系。模型經常能回答類似的問題： 什么是組件？ 改變組件有什么需求？不僅模型可以自動構建，測試和部署，并且你能建立可追溯性和信息透明度，自動生成發布信息和測試計劃。對事件的自動報告和反饋也實現在這個階段，同時這個階段也會存儲關于構建和其他事件的歷史報告。這些報告能為管理層提供信息，進而調整流程和優化工作流和工作量。
高級階段
在高級階段，當你開始頻繁發布和加工時，生產和服務變得足夠成熟。例如：商業指標被自然地設置成圖形化，這個時候，人們可以得到特定的實時信息，而且這些信息是他們特定需要的。在這個階段，實時圖形和其他的報告手段通常是隨著時間的推移反映整體趨勢。作為靜態代碼分析和單元測試覆蓋報告的輔助，在這個階段你可能會開始關注動態測試覆蓋和來自產品的分析信息，類似運行時環境，例如：當運行自動化集成測試的時候。
專家階段
至此，在這個分類中，專家階段通常包含改進的實時信息服務，它提供動態的自助實用信息和自定義的控制面板。這樣你就可以通過不同的組織邊界交叉引用和關聯報告及指標。這樣，信息就能讓你開闊針對持續改進的視角以及更易于驗證改變所帶來的商業結果預期。
跳轉到開始的行程
每個公司都是獨特的，當涉及到改變工作方式，如實施持續交付時，都會遇到特定的挑戰。成熟度模型給你了一個起點和計劃公司向持續交付轉型的基礎。根據該模型評估您的組織之后，你需要設定目標，并確定哪些實踐會給您的組織***的結果。如果有一些實踐你不想采取，你需要分析不采取他們的后果。決定實施策略是同樣重要的，例如你能從小事開始利用淡季在已存在的過程中一次提高一件事情。然而，從我們的經驗，你將有一個更好的成功實施的機會，如果你跳轉到開始的行程，有一個專門的項目有明確的命令和積極的目標例如降低循環時間。一個典型的持續交付實施項目需要的技能和能力是根據成熟度模型的分類和實踐，以實現一套讓組織能持續成長和完善的工具、方法和實踐的堅實平臺。
（點擊放大圖片）
關于作者
Andreas Rehn 是一個企業架構師，也是持續交付，開發運維，系統開發敏捷和精益方法的積極倡導者。在軟件開發許多學科有豐富的經驗，并對信息和管理的理論與實踐流程有深刻的理解。他致力于幫助客戶實現持續交付，并采用高效的和現代的軟件開發新方法改造他們的業務。
Tobias Palmborg 認為持續交付描繪了Scrum，極限編程和敏捷宣言曾打算的愿景。持續交付不只是關于自動化發布渠道，而是在一種藝術形態狀態里，如何獲得類似從面粉到面包的完整變更的流程 。他是一個歐洲***的在線游戲公司的前主管。Tobias目前正在為幾個客戶實施持續交付的項目。
Patrik Boström 是Diabol的創始人之一。 高級開發人員，有大型系統的操作經驗的架構師。他堅信持續交付和開發運維是敏捷和精益運動演化的自然的一步。要改變我們今天看系統開發的方式，要變化到下一個級別，我們將更多的時間在開發功能而不是手工做重復性的任務的級別。從下一級別中可以想像和理解從構思到它發布并帶來商業價值的道路。
英文原文：The Continuous Delivery Maturity Model
譯文鏈接：http://www.oschina.net/translate/continuous-delivery-maturity-model
