在之前的幾篇release manager階段總結中提到了比較多的術語概念，比如：精益、敏捷、Devops、持續交付、持續部署等，這些都是軟體工程領域常見的用詞，然而令人頭疼的是這些概念的重疊定義以及彼此之間的聯絡應該如何理解。那麼本篇我們就來嘗試解析一下這幾個核心概念。

首先需要說明的是這些聽起來像是哲學的概念自身有多個理解層級，比如從理念、從原則、從目標、從方法論等等。因此不同概念在不同維度理解起來彼此之間有重疊交集是正常現象。所以個人建議：不需追求完全清晰的區分開各個概念的涵蓋範圍，而是關注自己所理解的業務價值流，將各個概念與價值流的具體環節對應上，能夠契合自己的工作開展即可。

其次，按照從抽象到具體的演進，我將這些概念組織為下圖的流結構：

1. 處於最上層的是管理哲學：“精益”理念

“精益”理念來源於生產製造領域，核心思想為JIT（在需要的時間，按照需要的量，生產需要的產品）；

精益的兩個主要原則： 1.堅信前置時間是最佳度量指標之一；2.堅信小批量任務交付是縮短前置時間的關鍵因素之一；

精益理念極大的改善了生產系統的效率和穩定性，保障了產品的質量。

2.當“精益”理念進入IT軟體領域，即是“敏捷”理念

“敏捷”理念的目標是在更短的交付週期內更頻繁的交付可工作的軟體；

敏捷的關鍵舉措：良好的需求管理；頻繁迭代的週期sprint（建議不長於兩週）；站會和看板；特性驅動測試；測試驅動開發；結對程式設計；開發測試團隊融合；持續整合的技術手段；

敏捷保證了隨時都有可以向客戶展示的可工作的軟體版本。

3.“敏捷”理念相對注重產品管理/開發測試溝通協作，而當它擴充套件到運維領域時，即是“Devops”理念

“Devops”理念的核心是協作與溝通，它希望將釋出團隊&運維團隊與開發&測試團隊融為一體，打破阻隔開發和運維的那面牆；

Devops的關鍵舉措：自始至終所有團隊為同一個目標負責，團隊之間從推動式流程變為提拉式流程；

Devops更注重於組織和文化，狹義上是沒有太多的技術手段。比較強相關的是“基礎設施即程式碼”（Infra As Code），關注基礎設施環境的規範管理。

4.在“敏捷”和“Devops”的基礎上，再借助配置管理（版本控制等）和測試管理（自動化測試等）方法論，就形成了一種最佳實踐：“持續交付”

持續交付的目標是有能力隨時隨地一鍵部署可用的軟體版本到生產環境；

持續交付的關鍵舉措是持續部署，通過一些技術手段和工具軟體實現部署的自動化/無感知/可回滾等特性。

持續交付的對外呈現即是一條持續“流動”的“流水線”。

5.持續交付可被視為“Devops”的最佳實踐之一，或者Devops的擴充套件之一。Devops還可擴充套件為包括持續反饋和持續改進等實踐。

持續反饋：在持續交付流水線的每個階段中應用快速的反饋機制，實現問題的快速修復，從源頭控制質量。

持續改進：建立公正和學習的文化，·通過事後分析會議和故障注入來不斷增強可靠性，預留專門的時間段開展組織性改進活動。

最後奉上一張簡單的軟體業務價值流圖，後續將繼續基於價值流圖中的各關鍵環節進行學習總結：

需求 - - 開發模式 - - 變更 - - - 版本控制 - - -  環境管理 - - - 持續部署 - - - 監控反饋

                                   |                                                    |

                                   - - - 持續整合 - - - 自動化測試 - - -