本文作者：CODING - 廖紅坤
前言
隨著微前端、微服務等技術理念和架構的蓬勃發展，我們已經沒必要去討論為什么要前后端分離這種話題，前后端分離已成為互聯網專案開發的標準模式，前后端在各自的領域發展越來越縱深，
DevOps 視角的前后端分離
今天我們換個視角，從 DevOps 的角度來聊聊前后端分離，
專案協同
DevOps 體系中包含了敏捷開發方法論，而前后端分離前的開發模式無法做到敏捷，開發程序中前后端強依賴，需多次反復集成才能發布可用版本，違背了敏捷開發“適應性”的特點（適應性即歡迎變化），此外，前后端串行作業的方式拉長了版本發布周期，違背了敏捷開發“快速發布小版本”的理念，
- 前后端分離前的協作模式：
-
產品經理根據需求出原型
-
UI 出設計圖
-
前端做 html 頁面
-
后端將 html 頁面套成 jsp 頁面（前后端強依賴，后端必須要等前端的 html 做好才能套 jsp，如果程序中 html 發生變更，后端也要被迫調整，開發效率低）
-
集成出現問題
-
前端返工
-
后端返工
-
二次集成
-
集成成功
-
交付
- 分離后的協作模式：
-
產品經理根據需求出原型
-
UI 出設計圖
-
前后端約定介面、資料和引數
-
前后端并行開發（無強依賴，可前后端并行開發，如果需求變更，只要介面和引數不變，就不用兩邊都修改代碼，開發效率高）
-
后端 API 自動化測驗
-
前后端集成
-
前端頁面調整
-
集成成功
-
交付
代碼管理
前后端分離后，前后端代碼分開管理，后端不需要合并前端代碼，減少代碼合并沖突問題，此外，前后端分離后，后端可以根據業務型別自由選用編程語言開發不同的組件，實作松耦合，與微服務架構不謀而合，
測驗管理
前后端分離后，對應的測驗也分離了，由于后端只輸出 api 介面，于是可以很方便的進行自動化測驗，提早暴露問題，并且測驗成本很低，而前端可以不依賴后端，自己本地 mock 資料，待前后端介面對接后，測驗可以開始功能測驗，
交付部署
1913 年，福特汽車開發了世界上第一條流水線，大幅提高了汽車的生產效率，每 24 秒流水線就能制造一輛汽車，實作了汽車的規模化生產，福特也因此成了美國最大的汽車制造商，
交付部署包含持續集成和持續部署，其核心就是流水線，從代碼分離開始，前后端就形成了兩條并行的流水線，各自獨立編譯，構建，打包，發布，發布程序中不需要對方在場，出現了問題各自回退，
從專案協同、代碼管理、測驗到交付部署，需要一套完整的 DevOps 工具鏈支撐，比較典型的如 Jira + GitLab + Jenkins + Nexus + Kubernetes，但這些工具之間賬戶體系、操作習慣互不相通，試想團隊每加入一個新成員管理者都要在每個工具平臺為其添加賬戶，新成員也要花時間去逐一熟悉，這對管理者和新人都是不必要的負擔，這樣的背景下，我們可以采用 CODING 提供的一站式 DevOps SaaS 服務，快速實作前后端分離的 DevOps 最佳實踐，
快速實踐 DevOps
本文以信奉敏捷開發理念的互聯網團隊 突突突小分隊 為例，基于 CODING DevOps，以專案管理為起點，持續部署為終點演示快速實作前后端分離專案的 DevOps 最佳實踐，相關人員：
- 團隊 Leader： 老李
- 運維：小胖
- 測驗：小莉
- 后端：大熊
- 前端：阿強
技術堆疊：
- 后端（Python + Flask）：https://linrp.coding.net/p/front-back-cd/d/flask-backend/git
- 前端（React）：https://linrp.coding.net/p/front-back-cd/d/react-frontend/git
- 運維（Docker + Kubernetes）：https://linrp.coding.net/p/k8s-yaml/d/k8s-yaml/git
前提準備
- 使用騰訊云 TKE 創建一個 Kubernetes 集群： https://cloud.tencent.com/document/product/457/11741
創建專案和代碼倉庫
2020 年 10 月 26 日早上 11:00 整，突突突小分隊 Leader 老李在周會上召開了新專案啟動大會，由于是新專案，老李引進了 CODING DevOps 產品，目的是將 DevOps 理念和作業流貫徹到團隊實際作業中，規范團隊的開發、測驗和運維流程，并進一步提升產品發布效率，散會前老李當場創建兩個專案分別為 front-backend-cd 和 k8s-yaml，并表示給大家一天的時間了解 CODING DevOps 產品，
突突突小分隊 成員之間配合已經有相當的默契，在了解了 CODING DevOps 產品后，第二天（10 月 27 日）各自開始了有條不紊的作業：
-
后端大熊在專案
front-backend-cd中創建后端代碼倉庫flask-backend -
前端阿強在專案
front-backend-cd中創建前端代碼倉庫react-frontend -
運維小胖在專案
k8s-yaml中創建代碼倉庫k8s-yaml -
測驗小莉整理測驗用例，根據 Leader 老李提供的介面檔案撰寫后端 API 自動化測驗代碼
將
k8s-yaml作為獨立專案維護的原因是除了front-backend-cd專案，k8s-yaml也管理著其他專案的 Kubernetes yaml 檔案，單獨建庫的目除了方便對 yaml 檔案做版本控制，也便于開發和運維職責分明，開發不需要關注太多的運維基礎設施（Kubernetes），主要精力放在編碼、編譯和構建鏡像，
持續集成
代碼倉庫初始化后，后端大熊和前端阿強開始了愉快的編碼，同時在完成第一次代碼提交前，Leader 老李已經為團隊搭建好持續集成，并分別交由大熊和阿強維護，在下班前大熊和阿強完成了腳手架代碼，提交了代碼合并請求（MR，Merge Request），
細心的前端阿強發現合并請求詳情頁正運行一個叫 合并狀態檢查 的任務，請教 Leader 老李后得知是合并請求觸發的自動構建計劃， 其作用是：自動構建源分支與目標分支合并后的結果，能夠盡可能早地發現集成中的錯誤，如果合并狀態檢查失敗，評審者不用過早介入代碼 review 流程，開發者可以自行檢查代碼，
合并狀態檢查處點擊 詳情 可查看構建計劃的執行詳情：
果然，第一次合并狀態檢查失敗，前端阿強根據構建日志，發現了一個低級的字符拼寫錯誤，在內心深深的對自己鄙視一番后，立即修復，再次提交合并請求，
前后端代碼經 Leader 老李 review 合并到 release 后，會觸發相應的構建計劃，其起點都是代碼檢出，終點是將鏡像推送到制品庫，
持續部署
在后端大熊、前端阿強忙得熱火朝天的同時，運維小胖也沒有閑著，老李將小胖添加到團隊的【運維】用戶組，并授予【運維】用戶組部署設定權限，小胖跟著 CODING 持續部署的檔案開始一步步配置，
閱讀更多：CODING CD 幫助檔案
添加云賬號
作為云原生的先行團隊，突突突小分隊很早就采用騰訊云 TKE 作為生產環境，于是運維小胖添加了 TKE 型別的云賬號，
配置應用和部署流程
添加完云賬號后，運維小胖根據使用引導跳轉到 CODING 部署控制臺，分別創建了應用 flaskBackend 和 reactFrontend，
接著配置部署流程，運維小胖將 k8s-yaml 專案中的 manifest 檔案以及制品庫中的 docker 鏡像配置為部署流程制品，并在 Kubernetes 資源部署階段（Deploy（Manifest）-Deployment）參考，
如圖只有以
release-為前綴的 docker 鏡像才會成功匹配為發布制品
在人工確認階段，運維小胖將自己設定為確認人，并將測驗小莉加入通知人串列，
測驗小莉也會接收到人工確認通知，雖然沒有權限進行確認操作，但可以對發布程序 review，以降低發布故障率，
將應用與專案關聯
配置部署流程的程序中，由于對 CODING 部署控制臺不夠熟悉，一些小差錯讓運維小胖有點煩躁，但這些繁瑣的步驟不過是第一次麻煩點，接下來將應用與專案關聯后，發布程序就可以交給開發同學提交了，想到這兒小胖露出邪魅的微笑，
版本發布
新專案啟動的第三天（10 月 28 日），測驗小莉上班第一件事是查看后端 API 自動化測驗報告，中午飯點前前后端完成介面聯調，下午小莉在測驗環境上完成了功能測驗，是時候開始激動人心的 Staging（預發布） 發布了，
Staging 雖然不是最終的生產環境，但在 DevOps 實踐中其代碼、制品、應用配置等跟生產環境都是保持一致的，除了意外情況，Staging 發布驗證無誤后，就可以隨時發布到生產壞境，
老李新建了一個版本發布，命名為 release-20200428.1（相應地創建了同名的 tag），表示 2020 年 10 月 28 日的第一次發布：
此 tag 會觸發 CI 構建，在 Jenkinsfile 中獲取此 tag 的名稱并應用到 docker 鏡像，
在專案內提交發布
后端大熊和前端阿強在專案內提交發布單，選擇部署流程執行必需的制品（docker 鏡像選擇最新的版本 release-20200428.1），
人工確認
部署流程執行到 人工確認 階段，Leader 老李和運維小胖收到了人工確認通知，小胖點擊部署詳情跳轉到發布單詳情頁，確認制品資訊無誤后點擊 繼續執行，
2 分 43 秒后，發布成功！
查看發布資訊
在【基礎設施】->【集群】中查看發布成功的 Deployment 資訊，可看到鏡像版本與代碼版本一致，如果生產環境出現故障，可快速追蹤到對應的代碼版本，進行修復作業，
測驗小莉早已在運維小胖的提示下本地配置了 hosts，打開瀏覽器輸入 http://react-frontend.com 即可查看發布內容，這樣的版本肯定是不能發布到線上的，不過作為前后端分離的 DevOps 最佳實踐 Demo，它成功的完成了使命，
結語
突突突小分隊成功在五一勞動節前發布了第一個小版本，這次發布程序中，大家都感覺比以前舒心多了，
- 后端大熊和前端阿強不需要自己寫 k8s manifest，可以將時間和精力專注在業務代碼；
- 而運維小胖也不用像以前和女朋友約會時，還擔心開發請自己在測驗環境拉取更新鏡像，現在他們可以實作自助發布，小胖想如果以后 CODING 開發了 APP，打開手機即可一鍵完成人工確認操作，那小日子不要太爽；
- Leader 老李則表示對 CODING DevOps 是相見恨晚吶，早些年手工停服、ftp 上傳代碼、手工啟服的騷操作一去不復返了，
本文涉及的最佳實踐要點
- 前后端代碼倉庫分離：如本文中的
flask-backend和react-frontend - 開發和運維職責分離：運維配置云賬號、應用和部署流程，開發提交發布單
- 從代碼管理到制品發布，保持一致的版本規則，生產環境發現故障時可及時追溯相應的代碼版本
- Docker 作為交付標準，保證開發、測驗、生產環境依賴一致
- 運維人員使用獨立的 Git 倉庫管理 yaml 檔案，方便對 yaml 檔案做版本控制，開發不需要關心云基礎設施
DevOps 泳道圖
參考資料
1、前端開發的歷史和趨勢：https://github.com/ruanyf/jstraining/blob/master/docs/history.md
2、DevOps 的分與合：https://cloud.tencent.com/developer/article/1610668
3、《鳳凰專案：一個 IT 運維的傳奇故事》：https://book.douban.com/subject/34820436
4、《DevOps 實踐指南》：https://book.douban.com/subject/30186150
點擊立即體驗高效云上研發作業流
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/201099.html
標籤：其他