CI
持續集成指的是，頻繁地（一天多次）將代碼集成到主干。
持續集成的目的，就是讓產品可以快速迭代，同時還能保持高質量。它的核心措施是，代碼集成到主干之前，必須通過自動化測試。只要有一個測試用例失敗，就不能集成。
1.Gitlab的CI
從 GitLab 8.0 開始，GitLab CI 就已經集成在 GitLab 中，我們只要在項目中添加一個 .gitlab-ci.yml 文件，然后添加一個 Runner，即可進行持續集成。 而且隨着 GitLab 的升級，GitLab CI 變得越來越強大。
首先明白Gitlab CI 幾個基本的概念
1.1 GitLab-Runner
這個是腳本執行的承載者，.gitlab-ci.yml的script部分的運行就是由runner來負責的。GitLab-CI瀏覽過項目里的.gitlab-ci.yml文件之后，根據里面的規則，分配到各個Runner來運行相應的腳本script。這些腳本有的是測試項目用的，有的是部署用的。
1.2 .gitlab-ci.yml
這個是在git項目的根目錄下的一個文件，記錄了一系列的階段和執行規則。GitLab-CI在push后會解析它，根據里面的內容調用runner來運行。
簡單來說就是，你利用Git版本管理Push了本地代碼到Remote上(這里就是你gitlab.com)，然后Gitlab，就通知你的服務器，也就是Gitlab-runner來運行構建任務。然后跑測試用例，測試用例通過了就生成Build出相應的環境的代碼，自動部署上不同的環境服務器上面去。
1.3 配置.gitlab-ci.yml
配置好 Runner 之后，我們要做的事情就是在項目根目錄中添加 .gitlab-ci.yml 文件了。 當我們添加了 .gitlab-ci.yml 文件后，每次提交代碼或者合並 MR 都會自動運行構建任務了。
在.gitlab-ci.yml有一些需要講解的概念
1.3.1 Pipeline概念
一次 Pipeline 其實相當於一次構建任務，里面可以包含多個流程，如安裝依賴、運行測試、編譯、部署測試服務器、部署生產服務器等流程。我們的任何提交或者 Merge Request 的合並都可以觸發 Pipeline。如下圖：
+------------------+ +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+
1.3.2 Stages
Stages 表示構建階段，說白了就是上面提到的流程。
我們可以在一次 Pipeline 中定義多個 Stages，每個Stage可以完成不同的任務。
Stages有下面的特點：
所有 Stages 會按照順序運行，即當一個 Stage 完成后，下一個 Stage 才會開始
只有當所有 Stages 完成后，該構建任務 (Pipeline) 才會成功
如果任何一個 Stage 失敗，那么后面的 Stages 不會執行，該構建任務 (Pipeline) 失敗
因此，Stages 和 Pipeline 的關系就是：
+--------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |---->| Stage 2 |----->| Stage 3 | |
| +-----------+ +------------+ +------------+ |
| |
+--------------------------------------------------------+
1.3.3 Jobs
Jobs 表示構建工作，表示某個 Stage 里面執行的工作。
我們可以在 Stages 里面定義多個 Jobs，這些 Jobs 會有以下特點：
相同 Stage 中的 Jobs 會並行執行
相同 Stage 中的 Jobs 都執行成功時，該 Stage 才會成功
如果任何一個 Job 失敗，那么該 Stage 失敗，即該構建任務 (Pipeline) 失敗
所以，Jobs 和 Stage 的關系圖就是：
+------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ |
| |
+------------------------------------------+
2.CI/CD VUE應用
2.1 創建dockfile文件
FROM node:lts-alpine as build-stage
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
# production stage
FROM nginx:stable-alpine as production-stage
COPY --from=build-stage /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
該docker配置摁鍵拉取node鏡像，用來編譯我們的生產環境的應用，第二階段拉取nginx的鏡像用來運行我們第一階段構建的編譯應用。
執行daemon off的原因
加上了daemon off，nginx才能一直在后台持續運行，否則就會被docker進程終止，因為docker默認會終止pid為1的進程。Docker 容器啟動時，默認會把容器內部第一個進程，也就是pid=1的程序，作為docker容器是否正在運行的依據，如果 docker 容器pid=1的進程掛了，那么docker容器便會直接退出。
Docker未執行自定義的CMD之前，nginx的pid是1，執行到CMD之后，nginx就在后台運行，bash或sh腳本的pid變成了1。
所以一旦執行完自定義CMD，nginx容器也就退出了。
2.2 創建.gitlab-ci.yml文件
image: docker
services:
- docker:dind
stages:
- deploy
step-deploy-prod:
stage: deploy
script:
- docker build -t app/sgms.web .
# 這里是查看當前的服務器上有沒有正在運行或者存在我們之前運行過的項目容器，如果有刪除了
- if [ $(docker ps -aq --filter name=sgmsweb) ];then docker rm -f sgmsweb;fi
- docker run -d -p 81:80 --rm --name sgmsweb app/sgms.web
only:
refs:
- main
tags:
- sgmsweb
2.3 注冊git runner
網上資料很多，自行解決。
2.4 流水線編譯成功
線上也出現了我們想要的登錄頁面
參考文章
How to auto deploy a Vue application using GitLab CI/CD on Ubuntu 18.04
前端的gitlab的ci初嘗試
版權聲明：本文為博主翻譯文章+自己理解，部分代碼自己寫，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。 本文鏈接：https://www.cnblogs.com/JerryMouseLi/p/15380089.html