人多力量大vs.兩個披薩原則，聊聊持續交付中的流水線模式

在前面5期文章中，我們分別詳細介紹了持續交付體系基礎層面的建設，主要是多環境和配置管理，這些是持續交付自動化體系的基礎，是跟我們實際的業務場景和特點強相關的，所以希望你一定要重視基礎的建設。

本期文章是我們持續交付系列的第6篇文章，從本期開始，我們進入到交付流水線體系相關的內容介紹中。

持續交付流水線簡要說明

從一個應用的程式碼提交開始，到釋出線上的主要環節，整個流程串起來就是一個簡化的流水線模式。如下圖所示：

我們前面介紹了持續交付的多環境以及配置管理，而流水線模式的整個過程正是在這個基礎上執行，所以它的某些環節和要素與我們的多環境是有一些交叉的。比如，功能測試會線上下相關的幾個環境上完成，比如我們前面介紹到的開發聯調環境、專案環境和整合測試環境。

但是，它們要達成的測試目的是不同的：對於非功能驗收，我們會在線上的預發環境完成，因為預發環境更接近真實場景，所以像容量、效能、安全這些跟線上穩定性相關的能力驗收，越接近真實環境，效果越好。

後面幾期文章，我會結合我們的實踐，分環節來介紹。本期文章我們先看專案需求分解和開發模式選擇。

專案需求分解

持續交付我認為更多的是針對應用層面，所以專案需求分解這一部分，這裡我們就不展開講了。這裡我們的工作重點，就是將專案管理中的需求與持續釋出中的應用這二者很好地關聯起來。

比較通用的做法，就是要求業務架構師在做需求分析和功能設計時，要針對一個需求進行拆分，最終拆分成一個個的功能點，這些功能點最終落實到一個個對應的應用中，對應的邏輯體現就是應用程式碼的一個feature分支。

如下圖所示：

舉個簡單的例子，比如我們要做大促的優惠活動，同一店鋪商品購滿500元，可以使用10元店鋪內優惠券，同時還可以使用10元全站優惠券。

這樣一個需求最終拆解下來，可能需要店鋪應用支援多優惠活動的疊加，同時下單應用和購物車應用在計算價格時也要設定相關的優惠邏輯，這一個需求可能就拆出三四個功能點。

這樣做的好處就是，從一開始的需求管理維度，就確定了最終多個應用聯調、測試以及最終釋出的計劃和協作方式，從而就會讓我們明確同一個專案環境中到底需要部署哪些應用，這些應用的釋出順序怎樣安排。

比如，如果A應用依賴B應用，那麼B應用就必須優先發布。所以，上述這個過程對於專案進度管理、團隊協作以及最終的釋出計劃都是有幫助的。

講到這裡，你是不是又進一步感受到了運維的重要性呢？

當然，每個公司都有不同的專案管理方式，這裡我們只要明確做好需求拆分與應用功能的對應即可。

提交階段之開發模式選擇

在程式碼提交階段，我們遇到的第一個問題，就是分支管理問題。這反映出研發團隊協作模式的問題。

我們所熟知的開發協作模式有以下三種：

• 主幹開發模式。這也是極限程式設計裡提倡的一種模式，每一次程式碼提交都是合併到master主幹分支，確保master隨時是可釋出狀態。但是它對程式碼開發質量以及持續整合自動化和完善程度要求非常高，通常一般的團隊很難做到。

• gitfow開發模式。因為git的流行，gitfow是專門基於git程式碼管理的工作流工具，它的特點是在master分支之外，會有一條常駐develop開發分支，所有功能開發和缺陷修復都在這個分支上再建立分支。釋出時合入一個從master分支中籤出的release分支，最終釋出的是release分支程式碼，然後release分支再合併回master和develop分支。

如下圖所示：

• 分支開發模式。相對於gitfow模式，分支開發模式會簡單清晰很多。它的特點是，功能開發或缺陷修復從master簽出獨立的一個feature或bug分支，釋出前從master分支簽出一個release分支，並將要釋出的feature或bug分支合入。釋出完成後，release分支合入master分支。如下圖所示：

開發模式的選型原則

上面我分別介紹了三種開發模式的特點，那麼，在實際操作中，我們選擇哪一種比較好呢？

這裡的選型原則就是：一看這幾種模式的適用場景；二看我們實際的使用場景是怎麼樣的。

下面，我們分別看看主幹開發和gitfow開發這兩種模式。

• 主幹開發模式。它的特點是，所有的程式碼變更直接提交到master分支，這種情況比較適合規模較大的應用，這類應用自身集中了所有的需求功能點，且需求序列開發，需要多人協作共同完成同一個需求，釋出時間點明確、統一。

  這種模式最簡單，且便於管理，不需要再建立各種分支。我們之所以在極限程式設計中提倡這種模式，也是因為這種模式最簡單，最便捷，也最高效。因為我們的軟體架構在早期還是單體結構且分層架構的，程式碼相對集中，所以，主幹開發模式也是適用的。

  但是，在現實場景下，需求總是層出不窮的，所以就需要需求並行開發。這就會產生這樣一種情況：同一應用會有多個團隊在同時提交不同需求的程式碼，且每個需求釋出的時間點是不同的。

  所以如果採用主幹開發模式，就可能會將還沒有經過測試驗證的程式碼釋出到線上。這時，我們就需要在程式碼裡預設很多功能開關配置，這樣一來，在應用正式上線前，程式碼可以釋出，但是功能不開放，而這樣也必然會增加程式碼的複雜度。

  所以，就有了gitfow開發模式。

• gitfow開發模式能夠適應並行開發，解決上述我們所說的問題，而且gitfow工具能夠從技術層面幫我們解決各種分支合併問題。

  通過上面gitfow的圖示，我們可以看出，gitfow開發模式帶來的分支的管理代價還是比較高的，且隨著分支增加，開發人員之間的溝通協作成本也會隨之提高。

  同時，gitfow開發模式還是在程式碼相對集中的應用場景中更加適用，因此，基於這個應用完成較多的並行需求，就需要通過多個分支來管理。

  在現實場景中，儘管我們日常需求非常多，但是這些需求拆解下來的功能都是集中在某個或某幾個應用上的嗎？

  其實不然。我們從原來的單體或分層架構演進到微服務架構後，帶來的一個好處就是每個應用的職責更加明確和獨立，與此同時，針對應用的開發，團隊也更加自制，規模更小，符合“兩個披薩原則”。

  所以，一個需求拆解出功能，對應到每個應用上，這樣可以很好地控制並行的功能點數量，大大降低開發協作的溝通複雜度，即使有合併衝突問題，往往內部溝通一下就可以很快解決。

  而實際上，我們設想的這種複雜的gitfow場景，在微服務架構下的組織架構中極少存在。

  在此，經過對主幹開發模式和gitfow開發模式這二者的綜合對比，結合前面我對分支開發模式的介紹，我們可以看出，分支開發模式簡單清晰，在實際操作中更適合我們使用。

  最後，留個問題給你：你對於開發協作模式是如何選擇的？存在哪些問題？有什麼更好的建議？

精選提問

1. 系統功能一直是按固定版本釋出，因此基本都是選用了gitfow開發模式，不過對於新系統更加追求小步快走，在這個時候會用主幹開發模式。