3.8　它們之間是什么關系

XXX和XXX之間是什么關系？這是一個經常被問到的問題。這個問題沒有明確的、無爭議的答案。因為前面講的那些潮流和運動本身，就經常沒有公認的標準的定義、明確的內涵和外延，它們之間的關系也相應地變得復雜和模糊。某一項具體的實踐，常常出現在不同的“學派”中。而每個“學派”又大都有天然的傾向，把自己打造成無所不包：敏捷無所不包；DevOps無所不包；持續交付也出了2.0版，無所不包……

這里給出一些相對客觀、相對主流的觀點。大體上來說：

? 近二十年來的各種思潮，都是基于軟件工程，對軟件工程的補充、糾偏和發展。

? 敏捷和精益如今經常被一起提及。

? 持續交付是持續集成的自然延伸，而持續部署是持續交付的終極“夢想”。

? 持續交付的范圍和實踐與DevOps的范圍和實踐很接近，它們都把Ops拉進來，解決部署和環境相關問題，徹底打通從開發到上線的全鏈路。

? 從流程范圍來看，與DevOps相比，敏捷主要關注開發和測試之間的協作與融合，對部署到類生產環境進而到生產環境中的相關問題則關注較少。而精益的流程范圍則比DevOps更寬，它包括軟件開發全過程——既關注軟件定義側的精益創業，也關注軟件從定義到開發再到發布的完整價值流的效率。

? 從關注內容來看，盡管敏捷和精益都既包括管理實踐，也包括工程實踐，但在實際工作中提及敏捷和精益時，經常指的是它們的管理實踐，比如Scrum、看板墻等。而持續交付、DevOps更關注工程實踐，比如流水線、自動化測試、自動化部署等。

? 對工具的重視程度也是不同的。在敏捷看來，“個體和互動　高于　流程和工具”，而持續交付、DevOps都很重視開發工具平臺的建設，以自動化、自助化為導向。

那么，對上述這些軟件開發過程及其支持工具等方面的探索，與容器、微服務等軟件架構和技術方面的演進，又是什么關系呢？它們是相互成就的關系。例如，如果沒有以流水線為代表的流程自動化，那么當將應用拆分成多個微服務時，不論是測試還是發布都很麻煩。而在反方向上，容器化使得新建一個測試環境變得便宜和容易，于是可以有更多的測試環境，讓開發人員盡早進行測試，盡早發現和修復問題，而不用等到集成后再部署到測試環境中，由測試人員進行測試。

最后，本書和這些“流派”之間是什么關系呢？本書不是要開創一個新的“流派”。本書聚焦于軟件交付過程這個領域（或者說這個學科），努力把它成體系地講清楚、講明白。如果將來有了新的“流派”，那么本書的未來版本大概也會把它吸納進來。

在實際項目中，我們要面對軟件交付過程這個領域，結合具體情況，取“百家之長”，綜合運用。本書介紹“百家之長”，講解如何綜合運用。

[1]來源：鏈接2。

[2]來源：鏈接3。

[3]這個故事來自《精益思想》一書的第2章“價值流”。

[4]資源效率、流動效率的概念詳見《精益產品開發：原則、方法與實施》一書的第2章“精益產品開發的核心原則（上）：聚焦價值流動效率”。

[5]譯文：鏈接4；原文：鏈接5。

[6]除了構建、單元測試、代碼掃描，持續集成也涉及部署到測試環境并測試，但考慮到持續交付也會涉及這部分內容，所以我們將其放到“持續交付”部分來講。

[7]來源：鏈接6。

[8]來源：鏈接7。

[9]來源：鏈接8。

[10]參見《DevOps實踐指南》一書。

[11]來源：鏈接9。注意，原文位于境外網站上。