開始使用Travis CI持續集成你的項目吧

travis CI簡介

travis CI是一項廣受歡迎的持續集成服務，經過這項技術，咱們每次在向代碼託管平臺push咱們的代碼時，travis就能夠自動幫咱們完成一系列任務，好比自動將代碼部署到咱們的服務器，測試等等。而這一系列任務則須要咱們在項目主目錄下經過 .travis.yml 文件進行配置。

travis CI的工做原理也不復雜，它使用了代碼託管平臺好比 github 提供的 webhooks API ，當咱們在代碼庫執行某些操做（好比將咱們的代碼push到遠程倉庫）時，就會觸發 travis 進行自動化任務的動做。而具體完成什麼任務，則要根據咱們的須要經過配置文件進行配置。

須要注意的是，travis 執行自動化任務並非在咱們本地，也不是在咱們的目標服務器上，而是在 travis 控制檯（能夠理解爲在 travis 平臺上搭建的虛擬環境）中。它會根據咱們項目使用的編程語言靈活搭建所須要的構建環境。

下面咱們就直接上一個travis的實際使用案例：

自動部署代碼

像咱們每次寫完代碼，將代碼部署到遠程服務器，從新打包咱們的應用再重啓服務器這樣的體力活徹底能夠交給咱們的主角 ——— travis CI 來完成。

travis 根據咱們項目所使用的語言不一樣，所執行的任務也會有所不一樣，好比在 JavaScript 項目中，通常會先安裝咱們項目中以及構建過程當中所須要的依賴，而後執行 npm test 測試命令（執行 npm test 命令是在不定義 script 參數時的默認行爲，咱們也能夠根據實際狀況將 script 參數定義爲須要執行的命令集合），在命令執行成功以後咱們還能夠繼續進行其餘的操做，好比把代碼部署到目標服務器。以上就是一次 build 過程會完成的內容。

咱們的配置文件就是定義在依賴安裝先後，腳本執行成功(或失敗)以後等等一些時間節點須要 travis 幫咱們自動完成的工做。完整的 travis CI 構建過程包含如下這幾個階段：

截圖來源：travis CI官方文檔

以 JavaScript 項目爲例，按照官網的提示，首先須要在官網上對咱們要 build 的 github 項目啓用持續集成，接着就能夠在項目主目錄下添加一個名爲 .travis.yml 的配置文件，在裏面能夠定義咱們每次將本地代碼 push 到遠程倉庫時build所要完成的操做。例如：

language: node_js
node_js:
- 6.10.23
after_success:
- ssh xxx@123.123.123.123 -o stricthostkeychecking=no 'cd /projectMain && git pull && npm run build'
複製代碼

上面的配置文件指定咱們項目在 travis 控制檯中 build 所須要的構建環境，而且在 travis 執行測試成功以後鏈接遠程服務器，到服務器上的/projectMain目錄拉取最新代碼並打包。ssh命令能夠經過選項 -o stricthostkeychecking=no 來跳過對遠程服務器返回的 public_key 的檢查。

sshpass實現travis登陸服務器

在上面的配置中，travis控制檯還須要咱們手動輸入登陸服務器的密碼，可是咱們並不能和travis控制檯進行交互，並且ssh命令也沒有提供一個選項能夠用來指定登陸密碼。這時咱們有兩種方式可供選擇：

1. 使用 sshpass 傳遞服務器登陸密碼
2. travis 控制檯經過 ssh 私鑰文件實現免密鏈接服務器

首先介紹使用 sshpass 這種方式。sshpass能夠從特定的環境變量 SSHPASS 中獲取到登陸時所須要的密碼（使用時須要加上 -e 選項表示從環境變量中讀取）。這時候咱們的配置文件就變成這樣子：

language: node_js
addons:
  apt:
    packages:
    - sshpass
node_js:
- 6.10.23
after_success:
- export SSHPASS=[your password here]
- sshpass -e ssh xxx@123.123.123.123 -o stricthostkeychecking=no 'cd /projectMain && git pull && npm run build'
複製代碼

可是這樣還有一個問題，就是咱們把項目公開出去以後也就暴露了咱們的服務器帳號和密碼，這是至關危險的。travis 也替我們考慮到了這點，爲此也提供了一個用於加密鍵值對的工具。咱們能夠經過如下命令進行安裝：

$ gem install travis
# 在第一次使用此命令時須要登陸
$ travis login
複製代碼

而後咱們就能夠對咱們不想公開的內容進行加密了，好比：

# 添加 --add 選項能夠將加密以後的結果直接添加到.travis.yml文件中
$ travis encrypt DEPLOY_PASS=[your password here] --add
複製代碼

而後咱們在配置文件中就可使用前面定義好的 $DEPLOY_PASS 變量來替換掉咱們前面在配置文件中使用的明文密碼。至此，咱們就完成每次push代碼時，travis都會自動登陸遠程服務器，並更新服務器上的代碼。

加密私鑰文件

除了可使用sshpass這種方式來傳遞服務器登陸密碼以外，另一種能夠採用相似咱們平時使用ssh私鑰文件來實現免密登陸遠程服務器的方式，讓travis擁有服務器ssh私鑰文件來免密登陸到咱們的服務器上。

首先咱們須要在本地的系統中生成一對用於ssh鏈接的非對稱密鑰，並將公鑰文件拷貝到咱們的服務器上，具體過程能夠參考網上資料，這裏就不贅述。

而後就是如何讓travis控制檯訪問到我們在上一步生成的私鑰文件，這裏須要藉助travis提供的另外一個工具：travis encrypt-file 子命令，它能夠對咱們項目build過程要用到的，但又不能直接公開的文件進行加密，在加密過程當中能夠經過 --add 這個可選選項自動向咱們的travis配置文件中添加一個命令用於在build過程當中執行解密操做，以得到加密前的源文件。具體使用方式以下：

$ travis encrypt-file ~/.ssh/id_rsa --add
複製代碼

在項目主目錄下執行完上面的指令以後，咱們能夠看到當前目錄下多出了 id_rsa.enc 文件，該文件在後面travis解密獲得私鑰文件時須要被用到。同時咱們在當前目錄下的 .travis.yml 文件中也會發現多出了 before_install 這個字段，該字段指定的命令就是用來對 id_rsa.enc 文件進行解密，這就讓travis控制檯能夠訪問上面提到的私鑰文件了。最後的 .travis.yml 就長下面這個樣子（記得要刪掉before_install 這個字段指定的命令中的 --out 選項後面多餘的 \ 字符哦）：

language: node_js
node_js:
- 8.11.1
after_success:
- ssh xxx@123.123.123.123 -o stricthostkeychecking=no -i ~/.ssh/id_rsa 'cd /projectMain && git pull && npm run build && nginx -s reload'
before_install:
- openssl aes-256-cbc -K $encrypted_xxxyyyxxx_key -iv $encrypted_xxxyyyxxx_iv
  -in id_rsa.enc -out ~/.ssh/id_rsa -d
- chmod 600 ~/.ssh/id_rsa
複製代碼

這時候只須要爲配置文件中的 ssh 命令添加 -i 指定輸出的私鑰文件保存路徑便可，另外還須要在before_install字段增長一個命令，用來修改 ~/.ssh/id_rsa 文件的訪問權限（600），不然在後面 build 的過程當中由於私鑰文件訪問權限過於open而直接致使build errored。注意到生成的 before_install 字段對應的命令中還用到了兩個環境變量（$encrypted_xxxyyyxxx_key和$encrypted_xxxyyyxxx_iv），而它們的具體值能夠在 travis CI 管理後臺看到。

總結

本文主要介紹了travis CI這個工具的使用，並經過一個具體的🌰介紹瞭如何經過 travis CI 實現將咱們推送的代碼自動部署到服務器上。

整體來講，travis CI在解放咱們一部分生產力的同時，也爲咱們及時定位代碼在交付過程當中出現的問題提供了一個頗有效的方式。固然，在實際使用中，也發現這個工具自己存在的一些問題，好比build過程自己須要耗費大量的時間，不少操做在每次build都會從頭開始，但每每都是沒必要要的（好比安裝項目中所須要的依賴），固然對此travis CI也有本身的解決方案，能夠經過配置cache字段，緩存項目中的依賴，每次build只須要安裝須要更新的 package，而不是從新安裝所有依賴，這樣也就能夠縮短咱們的一部分等待時間。更多有趣的地方就等你發掘了~

更多細節能夠參考 travis CI 官方文檔