Ops.CI/CD-持續交付概要筆記

相關概念

持續集成：集成構建和測試的反覆持續過程
持續交付：在持續集成以後獲取外部對軟件的反饋再經過持續集成進行優化的過程
持續部署：將可交付產品快速且安全地交付用戶使用的一套方法和系統

持續交付價值

• 在保證交付質量的前提下，加快交付速度，從而更快地獲得市場反饋，引領產品方向，最終擴大收益。
• 對CTO：環境管理，整套標準規範落地，提升跨部門協做效率，快速恢復故障（回滾）
• 對team leader:只是傳承，專一業務而非工程，平穩節奏持續工做
• 對產品經理：即時體驗，熟悉進度質量，產品隨時可發佈

影響持續交付的因素

指望組織文化

緊密配合，集思廣益，自我驅動
方案：

• 成立項目管理辦公室（但不要把流程變得更加複雜），
• 獨立工程效能部門（成本高，小團隊不適用）
• 敏捷開發（我的能力要求高）
• 打破流程因素：耗時長，人工，信息報備

架構

系統架構

• 單體架構：項目編譯、迴歸、部署時間隨倉庫變大而變長
• SOA架構：服務拆分利於實施，考慮服務之間的依賴、環境隔離，中間件適配
• 微服務架構：非容器技術的微服務架構與SOA基本一致

部署架構

• 贊成的部署標準方式
• 發佈的編排次序（灰度發佈策略，如：金絲雀發佈/滾動發佈）
• markdown markup(服務拉入拉出機制)
• 預熱與自檢

DevOps:

技術(自動化運維，持續交付，高頻部署、Docker)/職能/文化/組織架構

分支策略

主幹開發（trunk based dev）

• 優勢：無需分支切換；頻繁集成衝突少、效率高
• 缺點：短板效應；藉助特性切換會引入新問題
• 適用項目：團隊系統設計開發能力強，有特性切換方案，快速迭代

特性分支開發

• 類別
  • git flow：廣泛認爲hotfix和release顯得多餘。適用項目：有預訂的發佈週期，嚴格執行發佈流程。
  • github flow：流程簡單易上手，適用項目：隨時集成便可發佈
  • gitlab flow：github flow基礎上衍生出3個特性分支production,enviroment,release,適用項目：隨時準備發佈，須要經過不一樣環境測試，對外發布維護不一樣版本。
• 優勢：不一樣功能互不干擾，保證主幹分支質量
• 缺點：須要即時merge，每一個分支的CI/CD環境不一樣

依賴管理特性

統一的命名規則，中心倉庫，配置文件，本地可解析

代碼回滾

我的分支回滾

能夠用git reset --hard

集成分支上線前回滾

可在gitlab上找到對應的merge request，點擊revert

集成分支上線後回滾

在集成分支頭上增長一個commit，該內容等於回滾後對應的commit

測試環境

• 5大類：開發環境，功能測試環境，驗收測試環境，預發佈環境，生產環境
• 成本：機器；管理（可用，配置，測試數據）；流程（溝通，測試）
• 自描述：
  • 定義ServerSpec(描述文件，服務器的全部身份信息)
  • 配置中心（構建時配置，打包時配置，運行時配置）
  • 服務自發現（根據服務類型，訪問路徑等自動生成對應的路由負載均衡配置等）

快速構建測試環境

• 虛擬機環境：物理機硬件配置，系統與網絡，利用工具自動配置環境
• 應用部署流水線：單應用標準化部署，並行，容錯：錯誤中斷/優先完成
• 環境變動：入口管理-約定大於配置，調用鏈管理-自發現，數據庫-SOA調用鏈/來自生產快速建立；建立和拆分、合併後的環境衝突。

容器

• 概念：是軟件的一個輕量的、獨立的、可執行包，包括了執行它所須要的全部內容：代碼、運行環境、系統工具、系統庫、設置。
• 特性：交付結果一致，交付自動化，交付個性化，交付版本控制

構建提速

• 升級硬件，搭建私有倉庫，使用本地緩存，規範構建流程，善用共建工具
• 持續集成工具：Travis CI,Circle CI,Jenkins CI,Gitlab CI

容器鏡像

DooD

(Docker-outside-of-Docker):是指經過加載宿主Docker socket和程序的方式達成重用宿主鏡像的目的。

• 優勢：複用鏡像共建環境，宿主機只需安裝Docker Daemon
• 缺點：內部環境需與外部一致，Docker Daemon出問題影響其餘容器。

DinD

(Docker in Docker):在容器中安裝一個全新的完整的隔離的Docker版本，該容器和外部的Docker系統徹底隔離。

• 優勢：內部是一個完整的鏡像構建環境
• 缺點：安全和文件系統問題，構建性能（鏡像緩存隨容器重啓而消失）

容器個性化&合規檢查

自定義環境腳本（.pass），平臺化環境選項與服務集市，自定義鏡像發佈

發佈流程

• 單機發布抽象步驟：
  1. 下載新的版本，不執行覆蓋；
  2. 通知上游調用方，本身如今爲暫停服務狀態；
  3. 運行命令 load 變動重啓服務；
  4. 驗證服務的健康情況；
  5. 通知上游調用方，本身服務恢復正常。
• 集羣灰度發佈：藍綠髮布，滾動發佈，金絲雀發佈
• 不可變模型（Immutable）：任何基礎設施的實例一旦建立則只讀，如需修改或升級只能建立新實例來替換

灰度發佈系統設計

• 類目：集羣，實例，發佈日誌，發佈歷史，發佈批次，發佈操做
• 2種時態：
  • 發佈中：展現處理的過程，結果，耗時，當前狀況
  • 未發佈時：顯示版本演進路線圖，當前各集羣，服務器上具體版本的狀況
• 3種結果：成功，失敗，中斷
• 4種狀況按鈕組合（誰發佈，誰運行）：
  • 開始發佈
  • 中斷髮布
  • 中斷或重試發佈（局部錯誤時）
  • 中斷或繼續發佈（發佈剎車時）
• 5個發佈步驟(演進自上述單機發布抽象步驟)
  • markdown：拉出集羣
  • download：根據版本號下載代碼包
  • install：中止服務、替換代碼、重啓服務
  • verify：啓動、預檢、預熱
  • markup：拉回集羣
  • 策略：單機單應用優於單機多應用，全量發佈優於增量發佈，header附加堡壘標識從而保證堡壘機流量定向

監控

用戶監控

（能夠經過打點收集，或者按期採集日誌的方式進行數據收集）

• 端到端監控：訪問量，成功率，響應時間，發包回包，地區，運營商，app版本，網絡類型
• 移動端日誌：系統崩潰異常
• 設備表現監控：CPU,內存，溫度，卡頓白屏，堆棧分析
• uid監控：獲取一個獨立用戶的具體狀況

網絡監控

（經過模擬手段或按期採樣進行收集）:公網內網監控

業務監控

（定義正確的指標，實時性）：單位時間內的訂單預測線

應用監控/調用鏈監控

（能夠經過中間件打點採集，也能夠經過日誌聯合分析進行數據採集）：收集應用層全量的數據進行分析，要分析的內容包括：調用量、響應時長、錯誤量等；面向的系統包括：應用、中間件、緩存、數據庫、存儲等；同時也支持對 JVM 等的監控。

系統監控

（按期採樣）：基礎設施的CPU、內存、I/O、磁盤、網絡鏈接等做爲監控指標。

其餘

代碼靜態檢查；破壞性測試：混沌工程（Chaos Monkey）；Mock 與回放

持續交付中的數據

穩定性指標

統計全部的故障時間（開始、結束、時長），計算過去三個月內這個時間段產生的持續交付平均業務量、業務量與月平均量相比的損失率

性能指標

• push 和 fetch 代碼的速度；
• 環境建立和銷燬的速度；
• 產生仿真數據的速度；
• 平均編譯速度及排隊時長；
• 靜態檢查的速度；
• 自動化測試的耗時；

交付能力成熟度指標

• 與代碼管理子系統相關的指標包括：commit 的數量，code review 的拒絕率，並行開發的分支數量。
• 與環境管理子系統相關的指標包括：計算資源的使用率，環境的平均大小。
• 與集成編譯子系統相關的指標包括：每日編譯數量，編譯檢查的數據。
• 與測試管理子系統相關的指標包括：單元測試的覆蓋率，自動化測試的覆蓋率。
• 與發佈管理子系統相關的指標包括：周發佈數量，回滾比率。

例移動 App 持續交付

生命週期

代碼及依賴管理、項目信息管理、靜態代碼檢查、構建管理、發佈管理、運營管理、熱修復。

細節

1. 利用發佈快車的發佈模式，能夠有效地管理客戶端的版本，保證研發工做按節奏持續向前進展；
2. 採用帶發佈分支的 GitLab Flow 配合發佈快車的模型，可使其作到物理落地；
3. 發佈快車自己也有一些弊端，好比對 Master 分支的合併，檢查不夠嚴格的話，會拖累項目進度，所以咱們採用改造構建通道的方式，避免了這個問題的產生；
4. 移動 App 的發佈，有其獨特的流程，一般是先內測，後正式發佈；但其流程相對固定，且容易自動化。因此，個人建議是，實現發佈的徹底自動化，以提升研發效率。

進一步，提高交付效率

1. 利用組件化的思想提高開發效率，但同時也會帶來組件依賴及發佈的問題；
2. 利用扁平化依賴管理的方法解決組件依賴和發佈的問題，同時採用二進制交付的方式，進一步提升構建效率；
3. 合理利用靜態代碼掃描、UI 自動化、自動 Monkey 等測試工具和方法，進一步提高測試效率；
4. 確保分發的精準性和穩定性，是提高發布效率的有效手段。

參考資料

持續交付36講