在前面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開發模式還是在代碼相對集中的應用場景中更加适用，是以，基于這個應用完成較多的并行需求，就需要通過多個分支來管理。
在現實場景中，盡管我們日常需求非常多，但是這些需求拆解下來的功能都是集中在某個或某幾個應用上的嗎?