分享一個CI/CD的自動部署想法
這里是Z哥的個人公眾號
每周五11：45 按時送達
當然了，也會時不時加個餐～
我的第「221」篇原創(chuàng)敬上
最近工作中正好在設(shè)計一個方案，以支持 CD 環(huán)節(jié)的第一個部署節(jié)點可以完全自動部署，并且整個環(huán)節(jié)中盡量減少人為干預的節(jié)點。
之前也沒有這塊的實戰(zhàn)經(jīng)驗，摸著石頭過河，想了一個方案，在這里分享給大家，歡迎你一起討論，相互學習。
我目前所在的公司 CI/CD 流程是這樣的。
相信大多數(shù)公司的 CI/CD 流程和上圖差別不大，基本上都是一個逐漸推進的直線節(jié)點。
在這個節(jié)點不斷推進的過程中，數(shù)據(jù)庫和配置的變更如何自動化，往往是面臨的最大問題。
我這次要做的事就是在圖中的 QA 環(huán)境之前增加一個 Alpha 環(huán)境，并且該環(huán)境的部署需要完全自動化進行。
那么自動部署過程中，我們有哪些原則可以被提煉出來，可以指導我們將這件事做成，并且往正確的方向持續(xù)進行呢？
我的理解是以下兩點：
在自動部署之前，盡可能提前檢測出部署后會導致該程序的上下游甚至整個系統(tǒng)不可用的風險。比如，通過靜態(tài)代碼檢測。
部署之后，盡可能廣地識別上下游以及整個系統(tǒng)的異常，及時回滾。比如，通過冒煙測試。
基于此原則，我構(gòu)思的方案是這個樣子：
在具體實施層面，覺得需要做以下幾件事，優(yōu)先級從高到低排列：
配置和數(shù)據(jù)庫變更文件的標準制定
能夠識別配置和數(shù)據(jù)庫變更文件的新增
能夠?qū)?gòu)建的鏡像、變更文件打包到一起通知到運維與 DBA（條件允許的話，直接在系統(tǒng)層面打通）
在部署 Alpha 環(huán)境前的可用性檢測。
每個程序提供健康檢查接口，用于檢測部署結(jié)果。
自動化的冒煙測試。用于檢測 Alpha 環(huán)境的可用性，并觸發(fā)回滾。
要做的細節(jié)工作還不有不少，但是核心工作就這么多。我們再來展開一下其中的每一件事。
/01 配置和數(shù)據(jù)庫變更文件的標準制定/
首先，自動化的前提是先標準化，為了實現(xiàn)自動化，我們需要先將標準確定好。針對變更文件的標準，我大致想了下是這個樣子。
01? 文件存放目錄定義
方案1：分別在 gitlab 倉庫里定義 infra_changes_conf 、 infra_changes_db 、deploy_dependencies 文件夾。
【建議】方案2：在 gitlab 倉庫里定義infra_changes文件夾，其中統(tǒng)一存放配置和 DB 變更、依賴描述文件，用不同的前綴區(qū)分。
02? 文件名的定義
文件名格式為：[conf/db/depend]_JiraID_自增序號。Jira ID 是Jira上的故事、任務、Bug 的 ID。示例：
conf_XXXProject-2564_1.yaml
conf_XXXProject-2564_2.yaml
db_XXXProject-2564_1.yaml
db_XXXProject-2564_2.yaml
depend_XXXProject-2564_1.yaml
depend_XXXProject-2564_2.yaml
文件名最后的自增序號一般用于兩種場景：
前一次構(gòu)建并發(fā)布 Alpha 環(huán)境成功，但因功能需求，需要額外增加配置并發(fā)新版。
配置或者 db 變更需要區(qū)分程序運行前還是運行后。
03? 文件內(nèi)容的格式
conf_ 文件內(nèi)容格式為 YAML 格式，結(jié)構(gòu)如下：
runtime: before|after #程序運行前 or 運行后store_type: config_map|apollo|nacos|... #配置的存儲類型service_name: xxxxxx #服務名remove_keys:key1key2.a.b #多級key 以 Properties 格式定義add_keys:-key1: value1: value2update_keys:-key1: value1: value2
同樣的，db_ 文件內(nèi)容格式為 YAML 格式，它支持兩種模式，結(jié)構(gòu)分別如下：
runtime: before|after #程序運行前or運行后db_type: mysql|mongodb|dynamodb|... #數(shù)據(jù)庫的類型ddls:- sql1- sql2dmls:- sql1- sql2
depend_ 文件內(nèi)容格式同樣為 YAML 格式，結(jié)構(gòu)如下
jira_ids:- XXXProject-2564- XXXProject-2564
相信你從文件格式中也能明白每一個屬性的意義吧？
/02 識別配置和 DB 變更文件的新增/
聰明的你可能已經(jīng)根據(jù)前面的《文件名的定義》部分內(nèi)容猜到了，就是通過 Jira ID 來識別。具體操作方式是：
研發(fā)將配置、DB變更文件與代碼一起提交到Gitlab 倉庫。
如果檢測到 Gitlab 的 commit 信息中帶 Jira ID，那么會觸發(fā)構(gòu)建，并且將該鏡像與 commit 中的 Jira ID 關(guān)聯(lián)。
然后根據(jù) Jira ID 去找 infra_changes 目錄中與該 Jira ID 相關(guān)的變更文件，將它們與鏡像放到一起。
/03? 將構(gòu)建的鏡像、變更文件打包到一起通知到運維與 DBA /
如果運維和DBA已經(jīng)有相關(guān)的自動化操作系統(tǒng)的話，可以直接在系統(tǒng)層面進行打通。否則的話，直接發(fā)出一個飛書或者釘釘消息就好了。
/04? 部署 Alpha 環(huán)境前的可用性檢測/
這個目前能想到的好像只有靜態(tài)代碼掃描了。
/05? 每個程序提供健康檢查接口，用于檢測部署結(jié)果/
健康檢查的作用在于，在部署完之后，通過調(diào)用每個系統(tǒng)的健康檢查接口來快速得到某個程序的自檢結(jié)果。畢竟只靠冒煙測試的話，整個效率會比較低。
具體的檢查項：
比如數(shù)據(jù)庫連接是否正常，所依賴的外部系統(tǒng)是否已經(jīng)就緒等等。
/06? 自動化的冒煙測試/
這個大家應該都知道，就不展開了。
大體上就這么多。等后面實際運用起來之后應該還會有一些迭代變化，到時候如果我覺得值得分享的話，再來和大家分享。
好了，總結(jié)一下。
這篇呢，Z 哥和你分享了我在目前團隊中正在做的一個與 CI/CD 相關(guān)的事情。
為了確保整個自動化過程的盡可能穩(wěn)定，我們需要基于兩個原則不斷思考和打磨整個過程。他們分別是：
在自動部署之前，盡可能提前檢測出部署后會導致該程序的上下游甚至整個系統(tǒng)不可用的風險。比如，通過靜態(tài)代碼檢測。
部署之后，盡可能廣的識別上下游以及整個系統(tǒng)的異常，及時回滾。比如，通過冒煙測試。
在具體的實踐過程中，主要有以下六個步驟：
配置和數(shù)據(jù)庫變更文件的標準制定
能夠識別配置和數(shù)據(jù)庫變更文件的新增
能夠?qū)?gòu)建的鏡像、變更文件打包到一起通知到運維與 DBA（條件允許的話，直接在系統(tǒng)層面打通）
在部署 Alpha 環(huán)境前的可用性檢測。
每個程序提供健康檢查接口，用于檢測部署結(jié)果。
自動化的冒煙測試。用于檢測 Alpha 環(huán)境的可用性，并觸發(fā)回滾。
希望對你有所啟發(fā)。
如果你有什么關(guān)于CI/CD的好想法，歡迎和我交流哈～
推薦閱讀：
原創(chuàng)不易，如果你覺得這篇文章還不錯，就「點贊」或者「在看」一下吧，鼓勵我的創(chuàng)作 ：）
也可以分享我的公眾號名片給有需要的朋友們。
如果你有關(guān)于軟件架構(gòu)、分布式系統(tǒng)、產(chǎn)品、運營的困惑
可以試試點擊「閱讀原文」