CI/CD 理想模型

云原生下交付理念

隨著k8s成為容器編排系統(tǒng)的事實(shí)標(biāo)準(zhǔn)，軟件構(gòu)建/交付發(fā)生了很大的變化悍缠。也許你還沒有體驗(yàn)到歷史車輪前進(jìn)的痕跡卦绣，但它確悄無聲息的一直前行。對于開發(fā)飞蚓、運(yùn)維人員 這也是一次小小的技術(shù)革命,既然是革命總有人(保守派)要為此丟掉原有的奶酪滤港，另外一批人(激進(jìn)的人士)或多或少出現(xiàn)一些彎道超車的機(jī)會，對于行業(yè)從業(yè)者來說既是機(jī)遇也是挑戰(zhàn)玷坠。傳統(tǒng)的運(yùn)維蜗搔、dba崗位需求將會越收越緊劲藐，開發(fā)不再只局限于產(chǎn)品邏輯開發(fā)八堡，會不同程度的參與ci部分的建設(shè)。即ci會慢慢向研發(fā)端下沉聘芜，由運(yùn)維提供構(gòu)建規(guī)范兄渺。解放ci構(gòu)建項(xiàng)目工程的自由度。
k8s以及(service mesh)服務(wù)網(wǎng)格的出現(xiàn)打破了互聯(lián)網(wǎng)構(gòu)建汰现、交付技術(shù)循序漸進(jìn)的腳步挂谍，從而實(shí)現(xiàn)不同以往的跨越(也可以稱之為技術(shù)進(jìn)步)
本文ci/cd理念便是在這種行業(yè)背景下產(chǎn)生的(個人感悟)叔壤。

• ci工具
  在當(dāng)今以用戶體驗(yàn)為主的互聯(lián)網(wǎng)生存環(huán)境下，前后端服務(wù)頻繁迭代將是常態(tài)口叙，隨之而來的代碼頻繁并發(fā)性的構(gòu)建將是常態(tài)炼绘。隨之而來的將是頻繁性、瞬時大并發(fā)量的構(gòu)建工程任務(wù)妄田。
  常見的ci工具有jenkins俺亮、githubci、gitlabci疟呐、輕輕量級drone等脚曾。他們都是很好的開源工具，用各自的理念,高效處理以上狀態(tài)下的構(gòu)建任務(wù)启具，其中jenkins是出現(xiàn)時間最早本讥，插件最多的ci工具。githubci是github最近發(fā)布 還處于beta狀態(tài)鲁冯。gitlabci是在gitlab在8.0版本開始加入的功能拷沸。

• jenkins2.0為適應(yīng)云環(huán)境的持續(xù)構(gòu)建
  1. 插件式構(gòu)建過程：整個構(gòu)建流程使用jenkins上各個插件，由jenkins提供參數(shù)選項(xiàng)晓褪，使用人員只需添加參數(shù)內(nèi)容堵漱。這也是jenkins1.0時代的主要構(gòu)建方式，2.0版本兼容了1.0的這種方式涣仿。
  2. pipeline：pipeline是2.0版本推出的勤庐，以適應(yīng)現(xiàn)代化流水線、申明式的構(gòu)建環(huán)境好港。其后續(xù)小版本逐漸增加了對云原生愉镰、k8s環(huán)境理念下的支持，其構(gòu)建過程不再是插件界面拼湊而成钧汹。而是由Groovy腳本維護(hù)控制丈探，文件內(nèi)容一般放置在項(xiàng)目工程根目錄下.jenkinsfile中
  3. Master/Agent架構(gòu)方式，支持瞬時大量的構(gòu)建任務(wù)
  4. 支持k8s拔莱，可以根據(jù)構(gòu)建任務(wù)量級動態(tài)伸縮Agent構(gòu)建節(jié)點(diǎn)碗降。
  5. pipeline正在逐漸向聲明式構(gòu)建靠攏，以便其適應(yīng)云原生環(huán)境的復(fù)雜構(gòu)建過程塘秦，這也是今后的主流方式讼渊。
• Github ci
  1. 既然是github的產(chǎn)品，肯定是要依賴github尊剔，對于沒有采用github的企業(yè)來說爪幻，無法直接使用，遷移到github代價(jià)也不小。
  2. 沒有Master/Agent方式
• Gitlab ci
  1. 采用pipeline方式挨稿，其構(gòu)建文件一般放在項(xiàng)目工程的根目錄下.gitlab-ci.yml 版本控制跟隨項(xiàng)目工程仇轻。
  2. 由Commit push操作觸發(fā)構(gòu)建操作
  3. 由于是gitlab內(nèi)置功能所以比較耗費(fèi)cpu、內(nèi)存資源奶甘，大量任務(wù)時硬件資源是其瓶頸篷店，畢竟gitlab原本就需要不少資源
  4. 無法動態(tài)伸縮節(jié)點(diǎn)，大量構(gòu)建任務(wù)時會出現(xiàn)排隊(duì)情況
  5. 沒有Master/Agent方式
• Drone：drone是一種基于容器技術(shù)交付的持續(xù)構(gòu)建臭家、交付系統(tǒng)船庇，采用聲明式，其構(gòu)建過程都可以是docker容器侣监，采用yaml配置文件管理鸭轮。
  1. 很新、很潮 基于容器實(shí)現(xiàn)橄霉，簡潔窃爷、復(fù)雜度低
  2. 任務(wù)構(gòu)建由git push觸發(fā)操作，目前沒有找到其它方式來進(jìn)行構(gòu)建操作
  3. 其配置完全由yaml文件控制
  4. 官方文檔不完善姓蜂、晦澀難懂
  5. 由于配置極簡按厘，功能不完善，不適合大量任務(wù)構(gòu)建使用

• 對比發(fā)現(xiàn) drone雖是云原生的钱慢，但是很多功能并不完善逮京，大量任務(wù)構(gòu)建時效率差，并且是以git push 來觸發(fā)任務(wù)構(gòu)建束莫，這在大多數(shù)情況下是合適的懒棉，但是極端情況下，這種理念并不適合览绿。需要有完善策严、規(guī)范的發(fā)布體系來支撐
  gitlab ci功能與gitlab深度耦合，并且不適合k8s環(huán)境下的構(gòu)建交付

• jenkins現(xiàn)在只是跟上了云原生饿敲、k8s環(huán)境下構(gòu)建妻导、交付的腳步。并不是真正意義上的聲明式構(gòu)建工具
  但其高效的master/agent方式怀各，完善的文檔倔韭、pipeline的引入，讓它還沒有落后他人瓢对。在其它c(diǎn)i工具沒有成熟寿酌、完善之前，jenkins還是比較穩(wěn)健的ci構(gòu)建工具沥曹。

• cd是什么

cd即持續(xù)交付份名，是在ci的生產(chǎn)物上進(jìn)行的經(jīng)過ci流程的一系列操作后產(chǎn)生了最終的交付物，但是我們怎么交付給最終用戶使用呢妓美，
交付過程中如何做到對用戶無感知
交付過程如何做到發(fā)布失敗對用戶沒有影響(或者說影響接近于0)
交付過程中如果新版本有錯誤如何做到安全的版本回滾呢
cd即是在這一復(fù)雜情況下誕生的僵腺。
在以用戶體驗(yàn)為中心的互聯(lián)網(wǎng)產(chǎn)品頻繁迭代、開發(fā)壶栋、時期我們必須接受失敗是一種常態(tài)辰如、失敗是安全的、低影響的贵试。
在此理念下我們就知道了CD要做什么琉兜，而不是關(guān)注于cd工具本身。
業(yè)界關(guān)于cd(持續(xù)交付)有以下實(shí)踐理念

• 自動化：這種理念下的交付對團(tuán)隊(duì)的技術(shù)能力要求很強(qiáng)毙玻，需要完善的制度來輔助處理自動化下各種復(fù)雜情況的出現(xiàn)豌蟋。其流程上將ci部分的交付產(chǎn)物通過自動化測試用例檢測通過后，發(fā)布到預(yù)發(fā)布環(huán)境桑滩，然后再次進(jìn)行預(yù)發(fā)布環(huán)境的測試用例檢測梧疲、通過后進(jìn)行生產(chǎn)環(huán)境灰度發(fā)布、或者金絲雀發(fā)布运准，第三次調(diào)用測試用例進(jìn)行檢測幌氮。這3個環(huán)境的測試用例是否相同取決于項(xiàng)目工程的復(fù)雜性。如果生產(chǎn)環(huán)境的灰度發(fā)布檢測通過胁澳，并且經(jīng)受了小部分用戶的使用檢測沒有異常该互，那么cd流程會繼續(xù)向前推進(jìn)、逐步加量直至全量發(fā)布完成新版本韭畸。在此期間各個環(huán)境如果測試失敗應(yīng)該由cd根據(jù)測試用例返回的結(jié)果來進(jìn)行項(xiàng)目工程回滾宇智，返回上一穩(wěn)健版本。
  大中型公司胰丁、以及產(chǎn)品活躍用戶少的初創(chuàng)公司采用此模式普筹，初創(chuàng)公司并不是也具備完整的技術(shù)來支持，只是用戶數(shù)量少隘马，發(fā)布過程出現(xiàn)問題也不會對公司產(chǎn)品產(chǎn)生太大的影響太防。它們基本采用mini版本自動化發(fā)布流程。

• 半自動化：這是在自動化cd基礎(chǔ)上為了更加穩(wěn)固酸员、安全的發(fā)布而做了一些妥協(xié)蜒车，放棄一定的敏捷性，提高發(fā)布質(zhì)量幔嗦。與自動化不同的地方在于每個環(huán)境的發(fā)布完成之后酿愧，再由研發(fā)人員、測試人員對功能再次驗(yàn)證后邀泉，再由發(fā)布人員進(jìn)行下一環(huán)境的發(fā)布操作嬉挡。以自動化測試為主钝鸽，人工測試為輔。吸收了自動化的敏捷性庞钢、舍去人工重度參與的繁瑣性拔恰。這里的發(fā)布人員有可能是開發(fā)，也可能是該項(xiàng)目的測試人員基括。運(yùn)維人員在此環(huán)境下的參與度弱化颜懊，主要負(fù)責(zé)基礎(chǔ)環(huán)境的優(yōu)化、完善风皿，敏捷性開發(fā)河爹。

• 人工參與方式： 由開發(fā)人員或者運(yùn)維人員同步發(fā)布平臺進(jìn)行各個環(huán)境發(fā)布操作，每個環(huán)境發(fā)布完成后由開發(fā)和測試進(jìn)行功能驗(yàn)證測試桐款，測試通過后通過IM或者口頭通知方式告知發(fā)布人員進(jìn)行下一環(huán)境的發(fā)布上線咸这，然后再次進(jìn)行驗(yàn)證測試，直至生產(chǎn)環(huán)境全量上線魔眨〈渡唬可以看出各個環(huán)境的連接人為的進(jìn)行了斷點(diǎn)隔離，以便應(yīng)對流程外的情況冰沙，而且也沒有自動化測試用例侨艾、或者以人工測試為主自動化測試為輔，目前大多數(shù)創(chuàng)業(yè)公司員工數(shù)50-100人時采用此模式較多拓挥，這是因?yàn)檫@類公司一般產(chǎn)品活躍用戶數(shù)量在50W-150W之間唠梨，對發(fā)布過程中的故障、問題容忍度低侥啤。對產(chǎn)品上線質(zhì)量要求嚴(yán)格当叭，但還沒有比較完善的技術(shù)來支持自動化、半自動化方式盖灸。

• CD工具

理念總要有工具或者技術(shù)來實(shí)現(xiàn)支撐蚁鳖，cd的工具有商業(yè)、開源基本這兩類赁炎，這里只探討非商業(yè)項(xiàng)目
大多數(shù)ci工具都提供原生醉箕、或者以插件形式擴(kuò)展集成了cd功能。jenkins徙垫、drone讥裤、gitlab
但是ci跟cd耦合在一起也會產(chǎn)生不便，如果某一版本發(fā)布一段時間后姻报，產(chǎn)品或者測試發(fā)現(xiàn)了bug或者莫個功能的缺陷己英，此時有兩種解決方案

1 研發(fā)修改代碼上線新的版本解決
2 暫時將版本回滾上一穩(wěn)健版本
當(dāng)采用回滾方式時由于ci與cd高度耦合無法直接回滾，(除非手動登陸服務(wù)器操作)
其回滾會再次經(jīng)歷ci過程吴旋，即使跳過ci也會留下一個空的構(gòu)建版本號损肛。
大中企業(yè)一般是采用ci工具厢破，然后使用自研的cd工具、或者平臺治拿；也有采用開源cd項(xiàng)目的摩泪。單純使用ci工具處理cd流程功能稍顯不足

k8s環(huán)境下的cd工具

• tekton

tekton 是一個強(qiáng)大而靈活的k8s原生開源框架，用來進(jìn)行持續(xù)集成和交付系統(tǒng)忍啤，對底層細(xì)節(jié)實(shí)現(xiàn)進(jìn)行抽象，可以實(shí)現(xiàn)跨多云平臺仙辟、多集群系統(tǒng)交付同波。可以跟jenkins配合使用

• flux

CNCF維護(hù)項(xiàng)目叠国，未畢業(yè)未檩。 基于gitops理念。在git中聲明性的描述系統(tǒng)的期望狀態(tài)粟焊，使用YAML來進(jìn)行強(qiáng)制一致性管理冤狡，所有更改都是通過git進(jìn)行，使用差異化工具來檢測狀態(tài)跟期望狀態(tài)的差異项棠；提供原子性和事務(wù)性悲雳，操作要么全部成功，要么全部失敗香追。

• drone

只支持容器環(huán)境合瓢，傳統(tǒng)服務(wù)器軟件交付不支持

• jenkins

利用k8s插件或者ansible進(jìn)行cd操作，拓展性差透典。

• wayne

360公司開源產(chǎn)品晴楔，功能齊全，可視化好峭咒，不錯的權(quán)限控制税弃、審計(jì)功能。缺點(diǎn)是靈活性不夠凑队，配置項(xiàng)太多操作繁瑣则果，沒有提供pv文件的管理。所以操作都要通過前端web頁面進(jìn)行操作漩氨，不利于后期自動化處理短条。