4.9　協調完成完整功能

4.9.1　背景

4.1節在介紹軟件交付的第1個策略時，講到軟件架構要細粒度、低耦合、可復用。有了好的架構，在實現某個用戶故事時，可能只需要修改一個微服務的代碼即可。然而，不論架構多么好，總會遇到需要為一個用戶故事修改多個微服務的代碼的情況。

4.2節在介紹軟件交付的第2個策略時，講到每個用戶故事的顆粒度要小，并且每次發布的用戶故事數量要少。這樣一來，可能每個用戶故事只需要修改一個微服務的代碼即可，也可能每個微服務都可以單獨發布，而無須連帶進行其他微服務的發布。然而，不論用戶故事顆粒度多么小，也不論每次發布的用戶故事數量多么少，總會遇到需要為一個用戶故事修改多個微服務的代碼的情況，也總會遇到一次發布包含對多個微服務的改動的情況。

事實上，正是從單體應用到微服務化這個趨勢，使得我們需要越來越關注如何實現和交付跨代碼庫的改動。當這種情況出現時，就需要進行一定的協調管理——可能是跨多個代碼庫的協調，也可能是跨多個開發團隊的協調，甚至是與外部系統、第三方之間的協調。下面我們來進一步分析。

4.9.2　開發全過程的協調

對于牽涉到多個代碼庫、多個開發團隊的軟件開發全過程的協調管理，從瀑布模型時代就在進行探索。瀑布模型本身就是用于整體系統從需求到發布的過程，當然它不夠好。在敏捷管理實踐中，目前業界有幾個重要的多團隊敏捷實踐，即SoS（Scrum of Scrum）、SAFe（Scaled Agile Framework）、LeSS（Large Scale Scrum）、DAD（Disciplined Agile Development）。而在精益方面，精益看板墻的一些復雜形式就是用來協調多個開發團隊之間的協作服務的。

4.9.3　交付過程的協調

當聚焦于軟件交付過程時，也有一些具體問題需要處理。這是本書特別關注的地方。

當一個特性包含對多個微服務的改動時，能否在特性對應的改動還在特性分支上、還沒有被提交到各代碼庫的集成發布分支時，就對該特性整體進行一些測試？答案是肯定的，但是需要動態創建或分配一個測試環境，專門用于測試這個跨多個微服務的特性。隨后把每個微服務的相應特性分支上的代碼版本部署上去，或者支持將各開發人員的本地開發環境加入這個測試環境中。

當一個特性包含對多個微服務的改動時，將該特性改動提交到集成發布分支，如何能夠保證各代碼庫中的相應特性分支都合入了集成發布分支？當（打算）把集成發布分支上的代碼部署到測試環境中進行測試時，能否自動計算出它包含了各個微服務上的哪些特性？進而，其中那些涉及多個微服務的特性，是否已經被完整包含了，而不是只包含該特性在一部分微服務上的改動？

當一個特性包含多個微服務甚至跨開發團隊時，應該如何規劃它的集成、測試和發布？如何協調相關的各個微服務甚至各個開發團隊的集成、測試、發布的節奏？整體跑版本火車似乎是一種方法，有沒有更好的方法？

當一次部署特別是一次向生產環境中的部署包含多個微服務時，該如何編排它們之間的順序，進行適當的串行和并行？如何自動按照這樣的編排部署？此外，無論怎樣編排，總是會存在在短暫的時間內，一個微服務的新版本的實例需要和另一個微服務的舊版本的實例一起運行的情況，同一個微服務也會有新舊版本的實例同時運行。此時，如何避免出現問題？如何保證服務的連續性？

當生產環境中出現故障，需要緊急回退最近的部署時，是只將某個微服務回退到原先的版本，還是需要回退一組微服務？同時還要考慮回退順序的編排，以及在回退過程中不要因為新舊版本并存而出問題。

以上討論的都是跨微服務的源代碼修改的問題。除了源代碼，數據庫表結構、數據庫中的數據也可能需要隨著源代碼一起修改，共同實現某個特性，共同實現軟件系統的演進。類似地，對環境及其配置也有可能需要做相應的修改。所以在討論上面的問題時，也要同時考慮涉及數據庫、環境、配置修改的情況。