敏捷、持續集成、持續交付

敏捷

2001年2月11日至13日，在美國雪鳥滑雪勝地，17位軟件大師聚到一塊兒，討論了各自提出的那些輕量級軟件開發方法的異同點，但願總結出它們的共性，以及與重量級瀑布方法的不一樣之處。參會者們包括來自極限編程、scrum、動態軟件開發方法、自適應軟件方法、水晶系列方法、特性驅動開發、實效編程的表明們，還包括但願找到「文檔驅動、重型軟件開發過程」替代品的一些推進者。會議的最終成果就是《敏捷軟件開發宣言》。同時還總結了敏捷軟件開發方法的十二原則，它們包括：
一、儘早地持續交付有價值的軟件，以便讓客戶滿意，這是優先級最高的事情
二、即使在開發階段後期，也歡迎需求變化。爲了讓客戶得到業務競爭優點，利用敏捷來應對變化
三、頻繁交付可工做的軟件，建議採用較短的交付週期
四、在整個項目過程當中，業務人員和開發人員可以一塊兒工做一段時間
五、圍繞積極的個體，創建項目團隊。給他們須要的環境和支持，並相信他們可以完成工做
六、不管團隊內外，傳遞信息效果最好和效率最高的方式是面對面交談
七、可工做的軟件是項目進度的首要衡量標準
八、敏捷過程促進可持續發展。項目主要干係人、開發人員和用戶應該能一直保持節奏
九、持續關注技術卓越和良好的設計，提升敏捷性
十、以簡潔爲本，它是極力減小沒必要要工做量的藝術
十一、最好的架構、需求和設計會從自組織團隊中涌現
十二、團隊要按期的反思「如何變得更有成效？」而後相應地調整自身行爲

敏捷軟件開發方法不是一種體系完整的方法論，而是知足上述宣言及原則的一簇輕量級軟件開發方法的集合

持續集成（CI）

持續集成做爲敏捷開發方法中的一個工程實踐，率先被更普遍的IT組織所接受，即便那些沒采納敏捷開發方法的團隊也會使用它，由於其強調的頻繁自動化構建和自動化測試減小了質量保障團隊的重複工做，也排出了開發團隊與質量保障團隊之間的溝通障礙。

CI場景起源於開發人員向代碼庫提交源碼，CI場景中的步驟一般是這樣的：
一、首先一名開發者向版本控制庫提交代碼。同時集成構建計算機上的CI服務器正在輪訓檢查版本控制庫中的變動
二、在提交發生以後，CI服務器檢測到版本控制庫中發生了變動，因此CI服務器會從庫中取得最新的代碼副本，執行構建腳本，該腳本將對軟件進行集成
三、CI服務器向指定的項目成員發出電子郵件，提供構建結果的反饋信息
四、CI服務器繼續輪訓版本控制庫中的變動

CI的特徵

• 與版本控制系統的鏈接
  版本控制庫的目的是經過一個受控的訪問庫來管理源代碼和其餘軟件資產的變動。爲開發者提供了一個「單一源碼位置」，這樣全部的代碼均可以從一個權威位置獲得，還能夠沿着時間回溯，取得源代碼和其餘文件的不一樣版本
• 構建腳本
  構建腳本是一段簡單的腳本或一組腳本，能夠利用它來編譯、測試、審查和部署軟件
• 某種類型的反饋機制
  CI的一個關鍵目標就是要提供集成構建的反饋信息
• 集成源代碼變動的過程（手工或CI服務器）

CI的價值

• 減小風險

  缺陷的檢測和修復變得更快
  軟件健康程度能夠測量：經過在自動集成過程當中包含持續的測試和審查，這些軟件產品的健康屬性如複雜度等能夠隨時追蹤

• 減小重複過程

  減小重複勞動的過程，讓人們有時間作更高價值的工做；
  經過對一些重要過程自動化，克服項目中某些成員對實現改進的抵制

• 在任什麼時候間、任何地點生成可部署的軟件
• 加強項目的可見性

  有效的決策：CI系統能夠對當前的構建狀態和品質指標提供及時的信息，或者對缺陷率和功能完成狀況的統計
  注意到趨勢：CI系統常常進行集成，咱們就可以注意到一些趨勢，例如構建成功或失敗，整體品質以及其餘相關的項目信息

持續交付（CD）

DevOps運動

DevOps的萌芽源於2008年8月敏捷大會多倫多站的一個臨時話題「敏捷基礎設施」。當時比利時獨立IT諮詢師Partrick Debois很是感興趣，而且分享了關於「將敏捷實踐應用於運維領域」。2009年10月，Patrick在比利時的根特組織了一個「DevOpsDays」社區會議，並正式啓用了「DevOps」這個術語。

DevOps在維基百科的定義爲：DevOps是一組軟件開發實踐，它結合了軟件開發（dev）和信息技術操做（ops），以縮短系統開發生命週期，同時根據業務目標頻繁地交付特性、修復和更新。

DevOps並不是一個標準、一種模式或者一套固定的方法，而是一種IT組織管理的發展趨勢，也就是說，經過多種方式打破IT職能部門之間的隔閡，改變IT組織內部管理的發展趨勢，使之更緊密結合，從而促進業務迭代速度更快。這種發展趨勢將會引發IT組織內部原有角色與分工的變化，甚至範圍更大，會影響到相關的業務組織。對互聯網公司來講，其軟件產品對業務發展起到極其關鍵的做用，業務結果與IT效能強相關，所以順應這一發展趨勢的動力更加明顯和迫切。

持續交付1.0

2006年，Jez Humble、Chris Read和Dan North共同發表了一篇題爲「the Development Production Line」的文章，文中討論了軟件部署帶來的生產效率問題，並首次提出「部署生產線」模式。如何使自動化部署活動更輕鬆有如下4條基本原則：
一、每一個構建階段都應該交付可工做的軟件，即對於中間產物的造成（例如搭建軟件框架）不該該是一個單獨的階段
二、用同一個製品向不一樣類型的環境部署，即將其與運行時配置分開管理
三、自動化測試和部署，即根據測試目的，分紅幾個單獨的質量關卡
四、這個部署生產線設計也應該隨着應用程序的發展而不斷演進

持續交付1.0提供的不少原則及方法是DevOps運動的具體實操指引，它們能夠爲企業的IT團隊將DevOps運動落地實施提供很是具體的指導。

從所涉及的角色來看，敏捷開發更多地涉及產品需求方、軟件開發工程師、和軟件測試工程師。DevOps更多地涉及軟件研發團隊（開發、測試工程師）與運維工程師，而持續交付1.0涉及產品需求方、軟件研發團隊和運維工程師。

持續交付2.0

精益思想

持續交付1.0關注從提交代碼到產品發佈的過程，而且提供了一系列工做原則和優秀的實踐方法，能夠提升軟件開發活動的效率。但在實際場景中，一些軟件功能在開發完成以後，對用戶或者業務來講，並無產生什麼影響，有些功能根本沒有用戶來使用。這些功能可能花費了團隊的不少精力才設計實現，這是一種巨大的浪費，這種無用的功能生產得越多，浪費就越大。

1996年Womack、Jones和Roos在《精益思想》中指出，精益思想是指導企業根據用戶需求，定義企業生產價值，按照價值流來組織生產活動，使價值在生產活動之間流動起來，由需求拉動產品的生產，從而識別整個生產過程當中不經意的浪費，並消除之。

2011年出版的《精益創業》其核心思想是，開發新產品時，先作出一個簡單的原型——最小化可行產品，這個原型的目標並非立刻生產出一個完美的產品，而是爲了驗證本身心中的商業假設。獲得用戶的真實反饋後，從每次試驗的結果中學習，再快速迭代，持續修正，在資源耗盡前從迷霧中找到通往成功的道路，最終適應市場的需求。

在精益管理理論中，浪費是指從客戶角度出發，對優質產品與良好服務不增長價值的生產活動或管理流程。在歸爲浪費的活動中又包括必要的非增值活動，如質量檢查，和純粹的浪費，如因質量問題致使的返工。

雙環模型

持續交付2.0是一種產品研發管理思惟框架。它將精益創業與持續交付1.0結合起來，強調業務與研發之間的快速閉環，以精益思想爲指導，貫徹「識別和消除一切浪費」的理念，經過一系列工做原則與實現，幫助企業以一種可持續方式高質量、低成本、無風險地快速交付客戶價值。
持續交付2.0是一個從業務問題出發，到業務問題解決的完整業務閉環，它由兩個相連的環組成：第一個環爲探索環，其主要目標是識別和定義業務問題，並制定出最小可行解決方案進入第二個環；第二個環爲驗證環，其主要目標是以最快速度交付最小可行方案，可靠地收集真實反饋，並分析和驗證業務問題的解決效果，以便決定下一步行動。