本文作者：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