摘要
DevOps 一詞源于 Development 和 Operations 的組合，即將軟體交付程序中開發與測驗運維的環節通過工具鏈打通，并通過自動化的測驗與監控，減少團隊的時間損耗，更加高效穩定地交付制品，
本篇文章將著重探討 DevOps 在 持續集成階段需要提供的能力，將對作業流的設計及流水線的優化思路做一個簡要講解，
隨著專案規模越來越大，功能特性與維護人員越來越多，特性交付頻率與軟體質量之間的矛盾日漸尖銳，如何平衡兩者成為了目前團隊亟需關注的一個重點，于是，落地一個完善的 DevOps工具鏈便被提上日程，
我們認為，從代碼集成、功能測驗，到部署發布、基礎設施架構管理，每一個環節都應該有全面且完善的自動化監控手段，并盡量避免人工介入，只有這樣，軟體才能同時兼顧質量與效率，在提高發布頻率的情況下保證可靠性，這是每一個成功的大型專案最終一定要實作的目標，
本篇文章將著重探討 DevOps 在 持續集成階段 需要提供的能力，將對作業流的設計及流水線的優化思路做一個簡要講解，
當我們在談論 CI 時，我們在談論什么
CI(Continuous Integration)，即持續集成，指頻繁地（一天多次）將代碼集成到主干的行為，
注意，這里既包含持續將代碼集成到主干的含義，也包含持續將原始碼生成可供實際使用的制品的程序，因此，我們需要通過 CI，自動化地保證代碼的質量，并對其構建產物轉換生成可用制品供下一階段呼叫，
因此，在 CI 階段，我們至少有如下階段需要實作：
- 靜態代碼檢查
這其中包括，ESLINT/TSLINT 靜態語法檢查，驗證 git commit message 是否符合規范，提交檔案是否有對應 owner 可以 review 等等，這些靜態檢查不需要編譯程序，直接掃描源代碼就可以完成，
- 單元測驗/集成測驗/E2E 測驗
自動化測驗這一環節是保障制品質量的關鍵，測驗用例的覆寫率及用例質量直接決定了構建產物的質量，因此，全面且完善的測驗用例也是實作持續交付的必備要素，
- 編譯并整理產物
在中小型專案中，這一步通常會被直接省略，直接將構建產物交由部署環節實作，但對于大型專案來說，多次頻繁的提交構建會產生數量龐大的構建產物，需要得到妥善的管理，產物到制品的建立我們接下來會有詳細講解，
利于集成的作業流設計
在正式接入 CI 前，我們需要規劃好一種新的作業流，以適應專案切換為高頻集成后可能帶來的問題與難點，這里涉及到的改造層面非常多，除了敦促開發人員習慣的轉變以及進行新流程的培訓外，我們主要關心的是原始碼倉庫的更新觸發持續集成步驟的方式，
流水線的組織形式
我們需要一個合適的組織形式來管理一條 CI 流水線該在什么階段執行什么任務，
市面上有非常多的 CI 工具可以進行選擇，仔細觀察就會發現，無論是 Drone 這樣的新興輕量的工具，亦或是老牌的 Jenkins 等，都原生或通過插件方式支持了這樣一個特性： ConfigurationasCode，即使用組態檔管理流水線，
這樣做的好處是相當大的，首先，它不再需要一個 web 頁面專門用于流水線管理，這對于平臺方來說無疑減少了維護成本，其次對于使用方來說，將流水線配置集成在原始碼倉庫中，享受與原始碼同步升級的方式，使得 CI 流程也能使用 git 的版本管理進行規范與審計溯源，
確立了流水線的組織形式后，我們還需要考慮版本的發布模式以及原始碼倉庫的分支策略，這直接決定了我們該以什么樣的方式規劃流水線進行代碼集成，
版本發布模式的取舍
在《持續交付 2.0》一書中提到，版本發布模式有三要素： 交付時間、特性數量以及交付質量，
這三者是相互制衡的，在開發人力與資源相對固定的情況下，我們只能對其中的兩個要素進行保證，
傳統的專案制發布模式是犧牲了交付時間，等待所有特性全部開發完成并經歷完整人工測驗后才發布一次新版本，但這樣會使得交付周期變長，并且由于特性數量較多，在開發程序中的不可控風險變高，可能會導致版本無法按時交付，不符合一個成熟的大型專案對于持續交付的要求，
對于持續集成的思想來說，當我們的集成頻率足夠高，自動化測驗足夠成熟且穩定時，完全可以不用一股腦的將特性全堆在一次發布中，每開發完成一個特性就自動進行測驗，完成后合入等待發布，接下來只需要在特定的時間周期節點自動將已經穩定的等待中的特性發布出去即可，這對于發布頻率越來越高，發布周期越來越短的現代大型專案中無疑是一個最優解，
分支策略
與大部分團隊一樣，我們原有的開發模式也是 分支開發，主干發布的思想，分支策略采用業界最成熟也是最完善的 Git-Flow模式，
可以看出，該模式在特性開發，bug 修復，版本發布，甚至是 hotfix 方面都已經考慮到位了，是一個能應用在生產環境中的作業流，但整體的結構也因此變得極為復雜，不便管理，例如進行一次 hotfix 的操作流程是：從最新發布前使用的主干分支拉出 hotfix 分支，修復后合入到 develop 分支中，等待下一次版本發布時拉出到 release 分支中，發布完成后才能合回主干，
此外，對于 Git-Flow的每一個特性分支來說，并沒有一個嚴格的合入時間，因此對于較大需求來說可能合入時間間隔會很長，這樣在合入主干時可能會有大量的沖突需要解決，導致專案工期無端延長，對此，做大型改造與重構的同學應該深有體會，
針對這一點，我們決定大膽采用 主干開發，主干發布的分支策略，
我們要求，開發團隊的成員盡量每天都將自己分支的代碼提交到主干，在到達發布條件時，從主干直接拉出發布分支用于發布，若發現缺陷，直接在主干上修復，并根據需要 cherry pick 到對應版本的發布分支，
這樣一來，對于開發人員來說需要關注的分支就只有主干和自己 working 的分支兩條，只需要 push 與 merge 兩條 git 命令就能完成所有分支操作，同時，由于合入頻率的提高，平均每人需要解決的沖突量大大減少，這無疑解決了很多開發人員的痛點，
需要說明的是，分支策略與版本發布模式沒有銀彈，我們采用的策略可能并不適合所有團隊的專案，提高合入頻率盡快能讓產品快速迭代，但無疑會讓新開發的特性很難得到充分的手工測驗及驗證，
為了解決這一矛盾點，這背后需要有強大的基礎設施及長期的習慣培養做支持，這里將難點分為如下幾個型別，大家可以針對這些難點做一些考量，來確定是否有必要采用主干開發的方式，
-
完善且快速的自動化測驗，只有在單元測驗、集成測驗、E2E 測驗覆寫率極高，且通過變異測驗得出的測驗用例質量較高的情況下，才能對專案質量有一個整體的保證，但這需要團隊內所有開發人員習慣 TDD（測驗驅動開發）的開發方式，這是一個相當漫長的工程文化培養程序，
-
Owner 責任制的 Code Review 機制，讓開發人員具有 Owner 意識，對自己負責的模塊進行逐行審查，可以在代碼修改時規避許多設計架構上的破壞性修改與坑點，本質上難點其實還是開發人員的習慣培養，
-
大量的基礎設施投入，高頻的自動化測驗其實是一個相當消耗資源的操作，尤其是 E2E 測驗，每一個測驗用例都需要啟動一個無頭瀏覽器來支撐，另外，為了提升測驗的效率，需要多核的機器來并行執行，這里的每一項都是較大的資源投入，
-
快速穩定的回滾能力和精準的線上及灰度監控等等，只有在高度自動化的全鏈路監控下，才能保證該機制下發布的新版本能夠穩定運行，這里的建設我會在之后的文章里詳細介紹，
大型專案中產物->制品的建立
對于大多數專案來說，在代碼編譯完成生成產物后，部署專案的方式就是登錄發布服務器，將每一次生成的產物粘貼進發布服務器中，生成的靜態檔案由于 hash 不同可以同時存放，html 采用直接覆寫的方式進行更新，
直接使用復制粘貼的方式來操作檔案的更新與覆寫，這樣既不方便對更新歷史的審計與追溯，同時這樣的更改也很難保證正確性，
除此之外，當我們需要回滾版本時，由于服務器上并沒有存放歷史版本的 html，因此回滾的方式其實是重新編譯打包生成歷史版本的產物進行覆寫，這樣的回滾速度顯然不是令人滿意的，
一個解決方法是，不要對檔案進行任何的覆寫更新，所有的產物都應該被上傳持久化存盤，我們可以在請求上游增設一個流量分發服務，來判斷每一條請求應該回傳哪一個版本的 html 檔案，
對于大型專案來說，回傳的 html 檔案也不一定不是一成不變的，它可能會被注入渠道、用戶自定義等標識，以及 SSR 所需要的首屏資料，從而改變其代碼形式，因此，我們認為 html 檔案的制品提供方應該是一個單獨的動態服務，通過一些邏輯完成對模板 html 的替換并最終輸出，
總結一下，在每次編譯完成后，產物將會進行如下的整理以生成最終的前端制品：
-
針對靜態檔案，如 CSS、JS 等資源將會發布到云物件存盤中，并以此為源站同步給 CDN 做訪問速度優化，
-
針對 HTML 制品，需要一個直出服務做支撐，并打包成 docker 鏡像，與后端的微服務鏡像同等級別，供上游的流量分發服務（網關）根據用戶請求選擇調起哪些服務負載進行消費，
速度即效率，流水線優化思路
對于一個好的工具來說，內部設計可以很復雜，但對于使用者來說必須足夠簡單且好用，
在主干開發這樣高頻的持續集成下，集成速度即效率，流水線的執行時間毫無疑問是開發人員最關心的，也是流水線是否好用的決定性指標，我們可以從幾個方面著手，提高流水線執行效率，減少開發人員的等待時間，
流水線任務編排
對流水線各個階段需要執行的任務我們需要遵循一定的編排原則： 無前置的任務優先， 執行時間短的任務優先， 無關聯的任務并行，
根據這一原則，我們可以通過分析流水線中執行的各個任務，對每一個任務做一次最短路徑依賴分析，最終得出該任務的最早執行時機，
巧用 Docker Cache
Docker 提供了這樣一個特性：在 Docker 鏡像的構建程序中，Dockerfile 的每一條可執行陳述句都會構建出一個新的鏡像層，并快取起來，在第二次構建時，Docker 會以鏡像層為單位逐條檢查自身的快取，若命中相同鏡像層，則直接復用該條快取，使得多次重復構建的時間大大縮短，
我們可以利用 Docker 的這一特性，在流水線中減少通常會重復執行的步驟，從而提高 CI 的執行效率，
例如前端專案中通常最耗時的依賴安裝 npm install，變更依賴項對于高頻集成來說其實是一個較小概率的事件，因此我們可以在第一次構建時，將 node_modules這個檔案夾打包成為鏡像供下次編譯時呼叫，Dockerfile 示例撰寫如下：
FROM node:12 AS dependencies
WORKDIR /ci
COPY . .
RUN npm install
ENV NODE_PATH=/ci/node_modules
我們給流水線增加一條檢查快取命中的策略：在下次編譯之前，先查找是否有該鏡像快取存在，并且，為了保證本次構建的依賴沒有更新，我們還必須比對本次構建與鏡像快取中的 package-lock.json檔案的 md5 碼是否一致，若不一致，則重新安裝依賴并打包新鏡像進行快取，若比對結果一致，則從該鏡像中直接取到 node_modules檔案夾，從而省去大量依賴安裝的時間，
流水線拉取鏡像檔案夾的方法示例如下，其中 --from 后跟的是之前快取構建鏡像的別名：
COPY --from=dependencies node_modules/ .# 其他步驟執行
同理，我們也可以將這一特性擴展到 CI 程序中所有更新頻率不高，生成時間較長的任務中，例如 Linux 中環境依賴的安裝、單元測驗每條用例運行前的快取、甚至是靜態檔案數量極多的檔案夾的復制等等，都能利用 Docker cache 的特性達到幾乎跳過步驟，減少集成時間的效果，由于原理大致相同，在此就不贅述了，
分級構建
眾所周知，流水線的執行時間一定會隨著任務數量的增多而變慢，大型專案中，隨著各項指標計算的接入，各項測驗用例的數量逐漸增多，運行時間遲早會達到我們難以忍受的地步，
但是，測驗用例的數量一定程度上決定著我們專案的質量，質量檢查決不能少，那么有沒有一種方法既可以讓專案質量得到持續保障的同時，減少開發者等待集成的時間呢？答案就是分級構建，
所謂分級構建，就是將 CI 流水線拆分為主構建和次級構建兩類，其中主構建需要在每次提交代碼時都要執行，并且若檢查不通過無法進行下一步操作，而次級構建不會阻塞作業流，通過旁路的方式在代碼合入后繼續執行，但是，一旦次級構建驗證失敗，流水線將會立即發出通知告警，并阻塞其他所有代碼的合入，直到該問題被修復為止，
對于某任務是否應放入次級構建程序，有如下幾點原則：
-
次級構建將包含執行時間長（如超過 15 分鐘）、耗費資源多的任務，如自動化測驗中的 E2E 測驗，
-
次級構建應當包含用例優先級低或者出錯可能性低的任務，盡量不要包含重要鏈路，如果自動化測驗中的一些測驗用例經過實踐發現失敗次數較高，應當考慮增加相關功能單元測驗，并移入主構建程序，
-
若次級構建仍然過長，可以考慮用合適的方法分割測驗用例，并行測驗，
結語
工欲善其事，必先利其器，騰訊檔案專案高頻穩定發布的背后，必定需要擁有強大基礎設施的支持，
本篇文章僅主要介紹了持續集成階段對專案進行的改造，持續部署、持續運營等階段的具體改造思路將在筆者接下來的文章中詳細說明，也歡迎大家多多探討，對其中需要改進或有誤的部分提出建議與斧正，
參考資料
- 《持續交付 2.0》—— 喬梁 著
- https://www.redhat.com/zh/topics/devops/what-is-ci-cd
- https://www.36kr.com/p/1218375440667012
關于我們
更多關于云原生的案例和知識，可關注同名【騰訊云原生】公眾號~
福利：
①公眾號后臺回復【手冊】，可獲得《騰訊云原生路線圖手冊》&《騰訊云原生最佳實踐》~
②公眾號后臺回復【系列】，可獲得《15個系列100+篇超實用云原生原創干貨合集》，包含Kubernetes 降本增效、K8s 性能優化實踐、最佳實踐等系列，
③公眾號后臺回復【白皮書】，可獲得《騰訊云容器安全白皮書》&《降本之源-云原生成本管理白皮書v1.0》
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/373816.html
標籤：其他
上一篇：Nginx基礎學習