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