ci/cd

CI/CD 理想模型

雲原生下交付理念

隨着k8s成爲容器編排系統的事實標準，軟件構建/交付發生了很大的變化。也許你尚未體驗到歷史車輪前進的痕跡，但它確悄無聲息的一直前行。對於開發、運維人員 這也是一次小小的技術革命,既然是革命總有人(保守派)要爲此丟掉原有的奶酪，另一批人(激進的人士)或多或少出現一些彎道超車的機會，對於行業從業者來講既是機遇也是挑戰。傳統的運維、dba崗位需求將會越收越緊，開發再也不只侷限於產品邏輯開發，會不一樣程度的參與ci部分的建設。即ci會慢慢向研發端下沉，由運維提供構建規範。解放ci構建項目工程的自由度。
k8s以及(service mesh)服務網格的出現打破了互聯網構建、交付技術按部就班的腳步，從而實現不一樣以往的跨越(也能夠稱之爲技術進步)
本文ci/cd理念即是在這種行業背景下產生的(我的感悟)。

• 現下的ci工具
  在當今以用戶體驗爲主的互聯網生存環境下，先後端服務頻繁迭代將是常態，隨之而來的代碼頻繁併發性的構建將是常態。隨之而來的將是頻繁性、瞬時大併發量的構建工程任務。
  常見的ci工具備jenkins、githubci、gitlabci、輕輕量級drone等。他們都是很好的開源工具，用各自的理念,高效處理以上狀態下的構建任務，其中jenkins是出現時間最先，插件最多的ci工具。githubci是github最近發佈 還處於beta狀態。gitlabci是在gitlab在8.0版本開始加入的功能。

• jenkins2.0爲適應雲環境的持續構建
  1. 插件式構建過程：整個構建流程使用jenkins上各個插件，由jenkins提供參數選項，使用人員只需添加參數內容。這也是jenkins1.0時代的主要構建方式，2.0版本兼容了1.0的這種方式。
  2. pipeline：pipeline是2.0版本推出的，以適應現代化流水線、申明式的構建環境。其後續小版本逐漸增長了對雲原生、k8s環境理念下的支持，其構建過程再也不是插件界面拼湊而成。而是由Groovy腳本維護控制，文件內容通常放置在項目工程根目錄下.jenkinsfile中
  3. Master/Agent架構方式，支持瞬時大量的構建任務
  4. 支持k8s，能夠根據構建任務量級動態伸縮Agent構建節點。
  5. pipeline正在逐漸向聲明式構建靠攏，以便其適應雲原生環境的複雜構建過程，這也是從此的主流方式。
• Github ci
  1. 既然是github的產品，確定是要依賴github，對於沒有采用github的企業來講，沒法直接使用，遷移到github代價也不小。
  2. 沒有Master/Agent方式
• Gitlab ci
  1. 採用pipeline方式，其構建文件通常放在項目工程的根目錄下.gitlab-ci.yml 版本控制跟隨項目工程。
  2. 由Commit push操做觸發構建操做
  3. 因爲是gitlab內置功能因此比較耗費cpu、內存資源，大量任務時硬件資源是其瓶頸，畢竟gitlab本來就須要很多資源
  4. 沒法動態伸縮節點，大量構建任務時會出現排隊狀況
  5. 沒有Master/Agent方式

• Drone：drone是一種基於容器技術交付的持續構建、交付系統，採用聲明式，其構建過程均可以是docker容器，採用yaml配置文件管理。

  1. 很新、很潮 基於容器實現，簡潔、複雜度低
  2. 任務構建由git push觸發操做，目前沒有找到其它方式來進行構建操做
  3. 其配置徹底由yaml文件控制
  4. 官方文檔不完善、晦澀難懂
  5. 因爲配置極簡，功能不完善，不適合大量任務構建使用

• 對比發現 drone雖是雲原生的，可是不少功能並不完善，大量任務構建時效率差，而且是以git push 來觸發任務構建，這在大多數狀況下是合適的，可是極端狀況下，這種理念並不適合。須要有完善、規範的發佈體系來支撐
  gitlab ci功能與gitlab深度耦合，而且不適合k8s環境下的構建交付

• jenkins如今只是跟上了雲原生、k8s環境下構建、交付的腳步。並非真正意義上的聲明式構建工具
  但其高效的master/agent方式，完善的文檔、pipeline的引入，讓它尚未落後他人。在其它ci工具沒有成熟、完善以前，jenkins仍是比較穩健的ci構建工具。

• cd是什麼

  cd即持續交付，是在ci的生產物上進行的通過ci流程的一系列操做後產生了最終的交付物，可是咱們怎麼交付給最終用戶使用呢，
  交付過程當中如何作到對用戶無感知
  交付過程如何作到發佈失敗對用戶沒有影響(或者說影響接近於0)
  交付過程當中若是新版本有錯誤如何作到安全的版本回滾呢
  cd便是在這一複雜狀況下誕生的。
  在以用戶體驗爲中心的互聯網產品頻繁迭代, 開發時期咱們必需要接受失敗是一種常態、失敗是安全的、低影響的。
  在此理念下咱們就知道了CD要作什麼，而不是關注於cd工具自己。
  業界關於cd(持續交付)有如下實踐理念

• 自動化：這種理念下的交付對團隊的技術能力要求很強，須要完善的制度來輔助處理自動化下各類複雜狀況的出現。其流程上將ci部分的交付產物經過自動化測試用例檢測經過後，發佈到預發佈環境，而後再次進行預發佈環境的測試用例檢測、經過後進行生產環境灰度發佈、或者金絲雀發佈，第三次調用測試用例進行檢測。這3個環境的測試用例是否相同取決於項目工程的複雜性。若是生產環境的灰度發佈檢測經過，而且經受了小部分用戶的使用檢測沒有異常，那麼cd流程會繼續向前推動、逐步加量直至全量發佈完成新版本。在此期間各個環境若是測試失敗應該由cd根據測試用例返回的結果來進行項目工程回滾，返回上一穩健版本。
  大中型公司、以及產品活躍用戶少的初創公司採用此模式，初創公司並非也具有完整的技術來支持，只是用戶數量少，發佈過程出現問題也不會對公司產品產生太大的影響。它們基本採用mini版本自動化發佈流程。

• 半自動化：這是在自動化cd基礎上爲了更加穩固、安全的發佈而作了一些妥協，放棄必定的敏捷性，提升發佈質量。與自動化不一樣的地方在於每一個環境的發佈完成以後，再由研發人員、測試人員對功能再次驗證後，再由發佈人員進行下一環境的發佈操做。以自動化測試爲主，人工測試爲輔。吸取了自動化的敏捷性、捨去人工重度參與的繁瑣性。這裏的發佈人員有多是開發，也多是該項目的測試人員。運維人員在此環境下的參與度弱化，主要負責基礎環境的優化、完善，敏捷性開發。

• 人工參與方式： 由開發人員或者運維人員同步發佈平臺進行各個環境發佈操做，每一個環境發佈完成後由開發和測試進行功能驗證測試，測試經過後經過IM或者口頭通知方式告知發佈人員進行下一環境的發佈上線，而後再次進行驗證測試，直至生產環境全量上線。能夠看出各個環境的鏈接人爲的進行了斷點隔離，以便應對流程外的狀況，並且也沒有自動化測試用例、或者以人工測試爲主自動化測試爲輔，目前大多數創業公司員工數50-100人時採用此模式較多，這是由於這類公司通常產品活躍用戶數量在50W-200W之間，對發佈過程當中的故障、問題容忍度低。對產品上線質量要求嚴格，但尚未比較完善的技術來支持自動化、半自動化方式。