快速構建持續(xù)交付系統(tǒng)一需求分析

1、2018/9/23講堂 持續(xù)交付36講 . 文章詳情34 | 快速構建持續(xù)交付系）：需求分析2018-09-20從今天這一篇文章開始， 就進入這個專欄的最后一個系列：實踐案例系列了。在這個系列里，我將通過 4 篇文章，以實際操作為主，帶你快速構建一套持續(xù)交付系統(tǒng)。當然，首先 要做的是，一起整理一下思路，看看 的系統(tǒng)具體要滿足哪些實際的需求，需要具備什么功能。然后，建立需求的 ，根據這些 ，展開具體的搭建工作。因此，在這篇文章中，我會以先介紹模擬團隊和項目，再提出具體持續(xù)交付需求的思路，羅列一些要模擬的背景，并為你解說這些場景。這樣做，可以幫助你在后面的三篇實踐文章中找到對應的需求點，也可以讓你

2、與現(xiàn)在團隊的持續(xù)交付體系作一番比較，找到相通之處，從而加深你對持續(xù)交付體系的理解。模擬團隊介紹我在第 7 篇文章“兩個披薩”團隊的代碼管理實際案例中，和你 了“兩個披薩”團隊的代碼管理實踐?；旧?， 可以把一個這樣的團隊看作是一個微型研發(fā)團隊。雖然這樣規(guī)模的一個團隊也可以很好地運用 即將搭建的持續(xù)交付系統(tǒng)，但是因為過于理想化而缺乏了典型性。1/634 | 快速構建持續(xù)交付系 ）：需求分析朗讀人： 1103 | 5.07M2018/9/23所以，為了更全面地介紹持續(xù)交付系統(tǒng)的搭建過程，我將要模擬的團隊規(guī)模擴大至 3 個“兩個披薩”團隊的大小。即，整個產品的研發(fā)，需要由這 3 個團隊合作完成。這

3、3 個團隊的分工，如下表所示：由這樣 3 個團隊組成的中小型研發(fā)組織架構，也是目前互聯(lián)網公司比較流行的。模擬系統(tǒng)介紹介紹完模擬團隊的情況，接下來， 需要再了解一下需要模擬的系統(tǒng)。對于持續(xù)交付體系來說，系統(tǒng)的業(yè)務邏輯并不是要解決的最重要 。因為不管業(yè)務邏輯如何，持續(xù)交付的過程大致都是相通的，都包括了代碼管理、環(huán)境管理、集成編譯管理、測試管理和發(fā)布管理這五大步驟。反而，系統(tǒng)之間如何集成 ，以及依賴關系、交付形式，關系著這持續(xù)交付系統(tǒng)應該如何實現(xiàn)，才是更重要的內容。在這里， 要模擬的這個系統(tǒng)，最終表現(xiàn)為移動 App 持續(xù)交付體系的形式，需要中間件、業(yè)務后臺，以及業(yè)務客戶端這 3 個團隊交付產物的協(xié)作

4、，才算是完整：首先，用戶通過團隊 3 交付的移動 App 進行系統(tǒng)操作；其次，移動 App 需要調用團隊 2 提供的業(yè)務 服務 War，獲取數(shù)據和處理業(yè)務邏輯；最后， 服務 War 需要依賴團隊 1 提供的業(yè)務中間件 Jar，完成底層操作，如配置 、緩存處理等。這三個團隊的依賴關系和交付產物，也決定了他們要采用不同的交付方式：團隊 1，有兩類交付方式：第一類是，中間件服務的交付，使用傳統(tǒng)的虛機部署，提供可部署的代碼包；第二類是，中間件組件的交付，使用 Jar 包發(fā)布，發(fā)布到組件倉庫。團隊 2 的交付方式是， 服務使用 Docker 交付，部署在 k8s 集群上。團隊 3 的交付方式是，標準的

5、iOS App 交付。這也是目前比較流行的移動互聯(lián)網系統(tǒng)的架構形式，當然其中也覆蓋了目前流行的容器交付。如果你現(xiàn)在要在一個微型研發(fā)團隊搭建這樣的持續(xù)交付系統(tǒng)，那你也可以根據這樣的架構形式做適當裁2/6團隊 1團隊 2團隊 3職責中間件服務業(yè)務 服務業(yè)務客戶端服務代碼管理GitGitGit語言JavaJavaReact Native交付產物服務 /Jar服務 /WarApp2018/9/23剪，去除一些不需要的功能，順利達成持續(xù)交付的目的。主體流水線的需求模擬團隊對整個持續(xù)交付流水線的需求如下圖所示：整個過程可以大致描述為：代碼合并到 master 后能夠自動觸發(fā)對應的集成編譯，如編譯通過則部署

6、到對應的測試環(huán)境下，部署成功后驅動自動化測試，測試通過則分批部署到生產環(huán)境。主體流水線發(fā)生的狀態(tài)變更，都需要通過審核人。通知發(fā)起人。這里的發(fā)起人就是代碼提交者和合并這條主體流水線，看上去很簡單、功能明確。但是，麻雀雖小五臟俱全。因此，各個步驟還都有一些細節(jié)實現(xiàn)上的要求。接下來，就一起看一下吧。代碼與配置管理相關的需求3 個模擬團隊的代碼分支策略均采用標準的 GitLab Flow 模型，要求是代碼通過 code review 后才能合并入 master 分支；合并入 master 分支后，能夠觸發(fā)對應的集成編譯。同時，需要代碼靜態(tài)掃描服務，幫助更好地把控代碼質量。這個服務的具體工作形式是：因為

7、代碼掃描是異步處理的，所以掃描過程將在代碼編譯通過之后開始。而掃描結果，則作為是否可繼續(xù)流水線的依據。這里需要注意的是，整個代碼掃描過程是異步進行的，所以在沒有得到掃描結果前，主體流水線將繼續(xù)進行。如果主體流水線已經執(zhí)行完，而代碼掃描還沒結束，也就是還沒有得到掃描結果的話，整條流水線需要停下來等待；而如果在執(zhí)行主體流水線的過程中，代碼靜態(tài)掃描的結果是不通過的話，那么就需要直接中斷主體流水線的執(zhí)行，此次交付失敗。構建與集成相關的需求對編譯與集成的要求，具體可以概括為以下幾點：首先，能夠同時支持傳統(tǒng)的部署包、Docker 鏡像，以及移動 App 的編譯和集成。而且能夠在觸發(fā)編譯時自動進行適配支持，

8、這樣才能保證各個團隊有新項目時無須再進行額外配置。其次，所有構建產物及構建歷史，都能被有效、地和。因為單從傳統(tǒng)的編譯驅動管理角度看，它以編譯任務為基準，需要清除過久、過大的編譯任務，從而的資源用于集成編譯。但是，從持續(xù)交付的角度看，需要完全保留這些內容，用于版本追溯。3/62018/9/23再次，各構建產物有自己獨立的版本體系，并與代碼 commit ID 相關聯(lián)。這是非常重要的，交付產物的版本就是它的唯一標識，任何交付物都可以通過版本進行辨識和追溯。最后，構建通道必須能夠支持足夠的并發(fā)量。這也就要求集成構建服務要做到高可用和可擴展，最好能做到資源彈性利用。打包與發(fā)布相關的需求要清楚打包與發(fā)布

9、的需求，就需要先了解各個團隊的部署標準和環(huán)境狀況。從這 3 個團隊交付產物的角度來看，他們需要的環(huán)境，可以描述如下：團隊 1，提供中間件服務。其測試服務器需要 1 個集群，2 臺虛擬機；生產環(huán)境需要 2 個集群，各 7 臺虛擬機。團隊 2 ，提供業(yè)務 服務。其測試服務器需要 1 個集群，2 個 Docker 實例；生產環(huán)境需要 2個集群，各 7 個 Docker 實例。團隊 3，交付移動 App。其需要的環(huán)境就是 測試市場。整個發(fā)布體系，除了要考慮標準的 War 包和 Docke 鏡像發(fā)布外， 還要考慮 Jar 包組件的發(fā) 布。因為團隊 1 的 Jar 包對應有兩類交付方式，所以對 Jar 包

10、的發(fā)布， 需要做一些特殊考慮：1. 測試環(huán)境可以使用 Snapshot 版本，但是生產環(huán)境則不允許；2. 即使測試通過，也不一定需要發(fā)布 Jar 包的每個版本到生產環(huán)境；3. Jar 包是發(fā)布到對應的組件倉庫，發(fā)布形式與其他幾類差別（比如，War 包、Docker 鏡像等）較大?；谝陨系目紤]， 需要對 Jar 包的發(fā)布做特殊的系統(tǒng)處理。另外，為了發(fā)布過程更加可控， 需要對代碼目錄、進程管理、日志格式等進行 的標準化。這部分標準化的具體內容，我將穿插在具體實現(xiàn)時再做詳細說明。自動化測試的需求在這里， 的自動化測試 ，選擇的是 TestNG，這也是業(yè)界最為流行的自動化測試 之一。對于測試，系統(tǒng)需

11、要注意的是，不要有一個測試任務失敗就中斷交付，最好是跑完所有測試任務，并收集結果。當然， 可以通過 TestNG ，很容易做到這一點。相反，另外一點倒是 要注意的，就是“停不下來”。比如測試 出現(xiàn)死循環(huán)。4/62018/9/23除此之外，自動化測試過程中還會發(fā)生許多意想不到的事情，特別是造成了一些破壞，使得測試過程無法正常繼續(xù)等情況。所以， 需要能夠處理這樣的異常，比如加上超時機制，使持續(xù)交付系統(tǒng)能夠繼續(xù)正常 。總結今天，我通過對要模擬的團隊和系統(tǒng)的介紹，引出了 即將實戰(zhàn)搭建的這套持續(xù)交付系統(tǒng)的需求。這里，我再概括一下整個持續(xù)交付體系的需求：要模擬的團隊有 3 個，分別為中間件團隊、后端業(yè)務團

12、隊和移動 App 團隊，3 個團隊最終產出一個可工作的移動 App。而模擬團隊在持續(xù)交付主體流水線的需求下，對各個主要模塊還有一些具體的需求：1. 代碼與配置：需要 code review，以及靜態(tài)代碼掃描；2. 構建與集成：能同時支持 Jar、War、Docker，以及 App，版本管理可追溯，支持高并發(fā)；3. 打包與發(fā)布：同時支持 Jar、War、Docker、App 的發(fā)布，以及 的部署標準；4. 自動化測試：通過 TestNG 驅動，實現(xiàn)全自動測試。從下一篇文章開始，我會通過開源工具和你一起解決這些需求，最終完成成這套系統(tǒng)的搭建。思考題在這一篇文章中， 模擬的是一個比較完整的團隊，而在實際項目