個人站點升級持續集成，自動構建和部署
前言
利用markdown+Hexo寫文章，整體體驗已經很棒。在寫作過程中，節省了我不少時間。
但是，美中不足的，就是發布的時候，需要手動輸入命令，build好文件，再用scp部署到服務器上。
本文，用於記錄解決這個痛點的過程。采取的解決方案就是持續集成。
以下是我用於部署個人站點的服務器概況：
服務器 - 阿裏雲ECS
系統 - CentOS 7
Git倉庫管理工具 - Gitlab（9.0.0）
CPU - 1核
內存 - 2 GB (乞丐版??)
正常情況下，註冊GitLab-Runner的服務器和部署生產文件的服務器是分開的。
因為窮??，我只有一臺服務器，所以兩者都部署到一起，大家就別太糾結這個點了。
一、持續集成
持續集成（Continuous integration），簡稱 CI，是指開發代碼頻繁地合並進主幹，始終保持可發布狀態的這個過程。其中包含持續構建和持續發布。
GitLab 8.0以上的版本就有提供持續集成服務。只要在項目中添加一個.gitlab-ci.yml文件，然後再添加一個Runner，即可進行持續集成。
我對自動發布博客的總體實現思路：
添加Runner用於監聽git push操作，然後用.gitlab-ci.yml指導步驟的執行，最後用shell腳本copy目標文件到指定目錄下。
二、註冊Runner
前提：請自行Google
gitlab-ci-multi-runner安裝教程。
1. 查看註冊必需的URL和token
瀏覽器打開一個GitLab項目，到 Settings-CI/CD Pipelines 下，可以看到一個 Specific Runners塊，主要有以下內容：
How to setup a specific Runner for a new project
1.Install a Runner compatible with GitLab CI (checkout the GitLab Runner section for information on how to install it).
2.Specify the following URL during the Runner setup:
http://gitlab.***.com/ci3.Use the following registration token during setup: TB8nknzg1woVb4pCx666
Start the Runner!
其中第2項的URL和第3項的token,是註冊Runner所必需的。
Runner憑借token註冊監聽對應的URL。
2. 在服務器上配置GitLab-Runner
這裏，我用SecureCRT連接上服務器，進行以下操作：
// 1.運行命令
sudo gitlab-ci-multi-runner register
// 2.根據提示輸入`URL`
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://gitlab.***.com/ci
// 3.根據提示輸入`token`
Please enter the gitlab-ci token for this runner:
TB8nknzg1woVb4pCx666
// 4.然後輸入runner的描述
Please enter the gitlab-ci description for this runner:
wall-runner
// 5.輸入標簽，可以多個，用逗號隔開即可
Please enter the gitlab-ci tags for this runner (comma separated):
test
// 6.是否運行無此標簽的構建
Whether to run untagged builds [true/false]:
true
// 7.將Runer鎖定到當前項目
Whether to lock the Runner to current project [true/false]:
true
// 8.選擇Runner的類型
Please enter the executor: ssh, docker+machine, kubernetes, docker, docker-ssh, parallels, shell, virtualbox, docker-ssh+machine:
shell這樣，一個GitLab-Runner就創建成功。刷新瀏覽器頁面，在Settings-CI/CD Pipelines 下可以看到runner已經綁定成功。
三. 配置.gitlab-ci.yml
在要添加持續集成功能的項目的根目錄下，創建.gitlab-ci.yml文件，編寫構建步驟。
在編寫之前，先大致了解下寫法：
# 定義stages
stages:
- install
- deploy
# 定義需要緩存的文件
cache:
paths:
- node_modules/
# 定義任務
job1:
stage: install
script:
- cnpm install
only:
- master
# 定義任務
job2:
stage: deploy
script:
- bash pub.sh
only:
- masterstages關鍵字定義Pipeline中的各個構建階段的先後順序cache關鍵字定義每個構建階段，不需要清除的文件- 每個構建階段有自己的別名，比如例子中的
job1和job2。也有真正的stage名,用於stages中標識先後的順序 script用於定義當前構建階段需要執行的命令only用於指定哪個Git分支的push操作才能觸發自動構建
以下是我在blog項目應用的.gitlab-ci.yml
# 持續集成
stages:
- install
- build
- minify
- deploy
cache:
paths:
- node_modules/
- public/
- db.json
# 安裝依賴
install_npm:
stage: install
script:
## - cnpm install [email protected] -g ## 同一臺服務器，不用多次安裝
- cnpm install
only:
- master
# 編譯，生成靜態文件
build_public:
stage: build
script:
- npm run build
only:
- master
# 壓縮文件
mini_file:
stage: minify
script:
- npm run minify
only:
- master
# 部署
deploy:
stage: deploy
script:
- bash pub.sh
only:
- master
四、用於部署的Shell腳本
前言中，有提到一個痛點就是scp部署文件。因為網速的原因，每次跑scp命令都要等好幾分鐘，電腦也不能關機。得等到傳輸完成，才可以。
升級為持續集成後，就不需要在本地跑命令了，都統一在服務器上跑。
而能代替文件傳輸這個步驟的，就是寫一個Shell腳本，讓服務器自動copy文件到對應的目錄下。
以下是我應用的Shell腳本pub.sh
#!bin/bash
cp -f -r -v ./public/* /mnt/blog/作用就是將public文件夾下所有文件copy到/mnt/blog/下。
五、權限問題
因為我是同一臺服務器上跑命令，所以當前Runner進程必須對相關文件夾有寫入和讀取權限。
所以，我把幾個文件夾的讀寫權限賦予Runner進程。
使用chown命令，對文件夾對擁有者權限進行更改：
chown wall-runner 文件路徑如果Runner服務器和生產環境服務器是相互獨立的，則可以使用ssh的方式去連接。配置好密鑰和繞過指紋檢查即可。
六、享受愉快的持續集成體驗
經過上述的配置，每次push代碼到master分支。Runner監聽到操作後，就會啟動自動構建，完成部署。
這樣，我發表新文章，只需要負責把markdown寫好，push代碼到GitLab。其他的工作，服務器會自動幫我做好。
寫好文章，我也可以愉快地關機休息，不用去打理其他的事，感覺真棒！
而且，每次構建記錄都有保存在GitLab上。可以在Pipelines中查看每次構建的結果。
還可以在README.md加入構建狀態圖標：
有需要的，就買個服務器折騰下，挺好玩的??
附上阿裏雲服務器的優惠券
個人站點升級持續集成，自動構建和部署