主要是透過gitlab runner CI/CD的流程
建立在windows環境下的build server
接著往下就是要建立測試環境
比較理想的流程就像上圖所示
那理想的情況，這幾個步驟的server應該各自獨立
因此在流程或server上的自動化切換就很重要
目前常見的docker就能快速方便的提供解決方案
gitlab上採用docker進行CI/CD
有提供Container Registry方便把docker image push上去
這類的文章已經很多
本篇提供一些在windows環境下，console與windows service的做法
在切換不同流程的指令時
在gitlab的.gitlab-ci.yml文件上以不同的stage來做切換
舉例如下，簡單分成testing_build與testing_deploy
目前在build與test都在同一個server下的runner執行
所以tags都採用一樣的yy-tag
未來若是build server與testing server不同
只需在testing_deploy的tag改成testing server上runner的tag即可
這樣去commit後
在gitlab就會在CI/CD的頁面出現Stage的狀態
同一次commit的CI/CD處理，是在同一個Pipeline下
而此Pipeline又拆分成兩個Stage，每一個Stage是一個獨立的Job
因此在CI/CD的Jobs頁面可以看到各個Job的狀態
上面兩個不同的Job但其Pipeline的id是相同的
所以上述這樣的狀況
會先執行testing_build再執行testing_deploy
切分好兩個Stage後
如果在同一台server上運作
檔案的交換就會顯得比較容易
但這邊要注意
每次Stage執行時，runner都會清除project資料夾
第一個Stage執行建置後所產生的檔案都會被清掉
(只會保留gitlab上面有的檔案)
雖然只要在第一個Stage執行時
在after_script中透過powershell的指令
直接把建置好的檔案複製到你的位置就行了
但這樣算是比較投機的作法，跨server就無法這樣執行了 XD
因此在不同的Stage之間分享檔案就很重要
gitlab就提供了一個分享檔案方式
artifacts
Artifacts is a list of files and directories which are attached to a job after it completes successfully. This feature is enabled by default in all GitLab installations.
直接看作法吧 XD
artifacts詳細的設定說明可參考官方文件
簡單對上面sample的內容說明
在artifacts底下的paths可加入要傳遞給下一個Stage的檔案或資料夾
expire_in則可設定這些檔案的保存時間
而要接手這些檔案的Stage需要加入
dependencies 加入上一層Stage的名稱：testing_build
這樣gitlab-ci.yaml的執行時
testing_builds的script都執行完之後，會把ETLTest.zip上傳到gitlab上
而當testing_deploy執行script前，就會從gitlab上下載ETLTest.zip
透過artifacts上傳的檔案在gitlab CI/CD的頁面可以看到
最右邊會出現artifacts的清單
甚至還可以從網頁上直接下載檔案
說明了artifacts的方式
就能透過此方法把build server建置後的檔案傳送給testing server/production server
windows常見的服務，主要是console執行視窗，以及windows service
而在gitlab runner上，可以透過powershell的語法來進行一些控制
這裡列舉一些目前有用到的語法
壓縮資料夾：Compress-Archive -Path {SourcePath} -DestinationPath {DestinationPath}
解壓縮檔案：Expand-Archive -Path {SourceFile} -DestinationPath {DestinationPath} -Force
同步資料夾：robocopy {SourcePath} {DestinationPath} /e /xo /purge
執行exe：start {ApplicationExePath} -wo {ApplicationDirectoryPath}
停止exe：Stop-Process -Name "{ProcessName}"
判斷exe是否執行中：
if((get-process "{ProcessName}" -ea SilentlyContinue) -eq $Null)
{ echo "Not Running" }
else
{ echo "Running" }
安裝服務：new-service -Name {ServiceName} -BinaryPathName "{ServiceExePath}"
啟動服務：sc.exe start {ServiceName}
停止服務：sc.exe stop {ServiceName}
移除服務：sc.exe delete {ServiceName}
因此在.gitlab-ci.yml上
組合上述需要用到的語法
應該就能完成gitlab CI/CD的流程
進行build server -> testing server (-> production server) 的自動化機制
沒有留言:
張貼留言