分享我在前後端分離專案中Gitlab-CI的經驗
阿新 • • 發佈:2020-06-12
長話短說,今天分享我為`前後端分離專案`搭建Gitlab CI/CD流程的一些額外經驗。
### Before
Gitlab-ci是Gitlab提供的CI/CD特性,結合Gitlab簡單友好的配置介面,能愉悅的在Gitlab介面檢視管道執行流程,並自然流暢的推動敏捷開發流程。
Gitlab-CI/CD的核心是搭建Gitlab Runner、編寫.gitlab-ci.yaml檔案。
詳細示例請參考:Gitlab CI/CD+ASP.NETCore.
> 本次前後端兩個專案使用同一個Gitlab Runner(shell模式),前端專案的gitlab-ci.yaml構建Job如圖:
![](https://imgkr.cn-bj.ufileos.com/2470e640-79e7-4bb4-a4b4-bdb96836135f.png)
### Round 1
**單個Gitlab Runner可為多個專案提供構建服務**,
> `gitlab-Runner register`命令只能接受一個註冊token,當時為支援多個專案,花了不少冤枉心思倒騰Gitlab Runner.
你可以為註冊的專案解鎖Runner,這樣Girlab Runner就可以為其他專案提供構建:
![](https://imgkr.cn-bj.ufileos.com/c5c0a3d5-8a9a-481e-b96d-157e63ee5cc5.png)
### Round 2
**使用Runner快取加快前端構建過程**
大家都知道npm_module被前端開發者詬病為毒瘤, 而Gitlab runner執行每次構建job之前都會清場,pull/fetch指定的程式碼再執行job, 這就導致每次`build` job會耗時很久(要拉取毒瘤)。
```
#!/bin/bash
cd packages/event-analysis
yarn config set registry http://registry.npm.gridsum.com && yarn --prefer-offline --frozen-lockfile
npm run build
```
以上是`build`任務的指令碼frontend.sh,總耗時3m33s,其中`yarn`命令拉取npm_modules耗時172.52s
![](https://imgkr.cn-bj.ufileos.com/920c6ca1-722e-4675-8544-722a3a4f0dd3.png)
![](https://imgkr.cn-bj.ufileos.com/9a2d18b9-83aa-4231-ae0c-a241f2a9b6c7.png)
gitlab runner支援快取
在.gitlab-ci.yaml 檔案中定義`cache指令`:
`cache`被用來在job之間快取檔案,更強大的是可以定義檔案依賴快取:
```
build:
stage: build
cache:
key:
files:
- packages/event-analysis/package.json
paths:
- node_modules
script:
- ./frontend.sh
tags:
- my-tag
```
快取key是`yarn`命令要用到的package.json,快取內容是npm_modules;
只要這個package.json檔案未變更,後續任務就會使用快取的npm_modules,而不用重建npm_modules依賴。
使用`runner快取`優化後`build`任務總耗時1m18s,其中`yarn`命令耗時22.83s:
![](https://imgkr.cn-bj.ufileos.com/7ee19a19-33d7-4ed6-aec6-31cd6a6710f1.png)
以上針對Gitlab-CI的使用經驗點到為止,足夠應對我當前專案,更多請關注:
## Reference
1. https://docs.gitlab.com/ee/ci/runners/#prevent-a-specific-runner-from-being-enabled-for-other-projects
2. https://docs.gitlab.com/ee/ci/caching/
Devops的圈子很大,上面的Gitlab-ci也只是點到為止,應付我當前的前後端分離專案.. 歡迎大家來捶我。