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初嘗試