2021/01/22 基于sharedLibrary進行CICD流程的優化(二)

第8章 內建robot自動化測試

8.1 配置robot-cases項目自動化

單元測試是開發寫的

通常是調用api

上面的測試用例是測試人員寫的

新開發版本對之前的版本有沒有影響

寫兩個流水線，從1個流水線調用另外一個流水線

初始化項目的目錄

送出一下

這樣就放到了gitlab上

建立jenkinsfile，可以給一個參數，然後去運作哪個項目的測試用例

env.comp，從環境變量了讀取comp參數，comp是component元件的意思

建立一個jenkins流水線

參數化建構就是要在建構的時候傳遞參數

這裡就會有一個參數

開始建構

還是用了jnlp

這裡就會有jnlp的pod

這裡完成了

都是ok的

8.2 library實作驗收測試任務觸發

robot-cases說明已經是可以成功運作的項目了

部署了myblog服務想要去檢測內建用例是否OK

比如下面兩個項目都需要測試，就是公共需求

公共需求可以用library去做，可以在sharelibrary去實作觸發任務的執行

comp就是這裡需要接收的參數

導入一下robot

加到jenkinsfile裡

送出一下

到達deploy的時候會執行內建測試

觸發測試

由上遊項目觸發

這樣就可以在myblog項目裡，可以去掉library裡的内容

第9章 多環境CICD流程實踐

9.1 多環境CICD實作目标及效果

這裡的jenkinsfile需要改一下

library改一下名字

現在涉及到的都是單分支單環境

這是送出git的commitid

develop分支其實可以去和開發環境做綁定

、

開發人員釋出develop分支後，自測沒有問題合并到master，想要發版，打一tag，就不是commitid了，K8S部署後，有一個內建測試環境，測試人員可以在這個環境進行測試

9.2 Jenkinsfile根據分支選擇任務

隻有一個K8S叢集，myblog部署到luffy名稱空間，要想區分環境，還需要建立名稱空間

develop分支部署到開發環境，master分支部署的時候執行測試

可以使用不同的jenkinsfile，但是使用可行性很差，因為有代碼合并的工作

對jenkinsfile還是一套，改進library，讓library根據不同的分支，做改進

~正規表達式

、

任務裡選分支

在develop分支裡執行

jenkinfile拿到master上，點選回放

這個階段被跳過了

需要在job的配置裡先比對到

這兩個通過library去實作

9.3 模闆化k8s資源清單

這裡隻有一個deployment檔案

但是還有其他的，ingress，svc，secret，configmap、這些都是手動準備好的，是以沒有去寫

ingress隻需要這些關鍵的

dev想要釋出到dev名稱空間，tag想要釋出到tag名稱空間

需要模闆化的内容，鏡像位址，命名空間，ingress域名資訊

可以在library裡做模闆化

*ingress域名也需要模闆化

*

、還有service也拿過來

configmap

secret

這樣就可以把所有資源清單檔案都建立好

下一步實作library的替換

9.4 實作library模闆替換

第一步實作test，dev

tag就是比如要發版的時候可以打一個tag

上面這段代碼在master裡執行一下

這裡就掃描到之前打tag的标簽

立即建構

tag分支執行

這裡的tagname就有值了

這樣就可以通過tagname知道，是标簽觸發，還是分支觸發的建構，标簽觸發的建構會多一個tagna’me，分支觸發的不會有tagname

原有的sed改成調用函數

預設名稱空間是dev

如果是tag标簽釋出的就釋出到test

目前隻實作了dev和test名稱空間，後面可能有內建測試，其他項目組如果都需要CICD的流程，下面的tplHandler項目就還需要去修改

每個環境對應的configmap不一樣

約定configmap裡key的值

上面的值是要替換yaml檔案裡的值

這樣寫好，library就不用修改，隻需要修改configmap就行

也就是每個命名空間裡維護一個configmap，名字是固定的，devops-config，對tplhandler進行修改

getresource是去拿同一名稱空間下的。一個資源類型的值讀出來，就是讀json檔案，傳回json對象

要去讀configmap裡的data值

應該是這樣。groovy裡不支援for循環

9.5 準備開發和測試環境

luffy這個名稱空間先删除，pod都先置0

mysql在dev名稱空間裡已經啟動了

這裡換成test就直接是在test名稱空間下建立mysql了

在test環境裡再建立

準備開發環境下的檔案

建立configmap

同時再測試環境也要做一次相同的操作

這裡問的條件變量，直接修改即可

有新檔案添加後，要執行add

develop會部署到開發環境

9.6 驗證多環境自動部署

這裡已經再建構了，隻要develop代碼送出就開始建構部署到dev環境

這裡沒有做migrate，是以不是1

這裡就變成1了

在library裡去讀了devops-config這個值，讀完循環去替換

循環做替換

替換image，然後getresource

develop分支跳過了測試

開發環境好了，送出代碼到develop分支會部署到develop分支上

merge一下

不要把source删掉

不想讓master顯示

這裡隻要顯示develop或者v.*

develop的分支做了改動都到這裡了

多個人開發了想要釋出，打一個tag

和master代碼一緻

想要自動觸發，但是沒有實作

9.7 實作打标簽後自動部署

可以識别tag，但是不能自動部署

安裝這個插件

裝了插件就有了新的一行

普通的分支都可以通過

忽略一天内的tag，tag超過7天了也忽略

7天以後的tag就看不到了

tag觸發了一次執行

先把表初始化好

已經在running了

做了一個test

test是可以通路到的

9.8 優化鏡像tag邏輯

dev分支是可以拿到commit id，其實tag分支沒有做處理，沒有commitid

在去做build的時候，傳遞了git commit

判斷是否是tag分支

如果是tag分支，就指派

打一個tag

開始建構

這裡修改的

tag就更新上去

現在推到develop分支

dev分支就檢測到了，去運作

sornar檢測失敗，重複代碼太多了

把這個苛刻的要求删掉

再去建構

起了個新的

通路開發環境

已經優化完成了

第10章 本章小結

10.1 本章小結

看一下舊版的library，很多寫死的，現在就沒有

推到碼雲上了

項目裡定義的全是模闆，deploy全是模闆，隻要是環境綁定的都替換成了模闆，資料是定義的devops_configmap，sharelibrary去實作對模闆的替換