webpack + Travis CI 自動部署項目應用

咱們知道 Github Pages 是 Github 免費提供給用戶展現頁面的一項服務。當咱們完成項目開發後，想將頁面部署到 Github Pages 時，該要怎麼操做呢？

能夠在 GitHub 的儲存庫設置中設置用於展現頁面的分支，該分支只保留構建後的靜態資源，也就是源碼與編譯後的靜態資源分離。按照傳統的作法是：手動運行編譯命令，編譯後再複製到指定分支中。這樣操做很繁瑣，但使用 Travis CI 持續集成服務以後就能夠不用操心這些事了。

概念

既然咱們要使用 Travis CI，首先得搞清楚人傢俱體是幹嗎的吧？

Travis CI 是一個 持續集成(Continuous integration, CI)。它與 git 相耦合，每當有 commit 提交時，它將自動觸發構建與測試。若運行結果符合預期，纔將新代碼集成到 主流(mainline) 中，這樣使應用更加健壯。

值得注意的是，Travis CI 提倡每次 commit 都是獨立較小的改動，而不是忽然提交一大堆代碼。由於這有助於後續構建失敗時能夠回退到正常的版本。

運行構建時，Travis CI 將 GitHub 存儲庫克隆到全新的虛擬環境中，並執行一系列任務來構建和測試代碼。若是這些任務中的一項或多項失敗，則將構建視爲已損壞。若是全部任務均未失敗，則認爲構建已經過，Travis CI 會將代碼部署到 Web 服務器或應用程序主機中(在本文中是指 Github Pages 服務)。

準備

在使用以前，須要準備一個 Github 的帳號對 Travis CI 進行受權。

1. 接着經過 Github 的帳號登陸 Travis CI，點擊 SIGN IN WITH GITHUB。
2. 點擊後會被重定向到 Github 進行受權。
   
3. 受權後，如果第一次登陸的話會被重定向至引導頁:
   

4. 點擊引導頁第一步的按鈕，使用 GitHub Apps 激活儲存庫。能夠選擇給所有儲存庫都激活，也能夠激活指定儲存庫。本文以 <username>.github.io 爲例:

   注意: 這個 username 是你本身的 Github 用戶名。筆者的 username 爲 anran758 那儲存庫的名字就爲 anran758.github.io。

   

5. 激活後會被重定向到設置頁，點擊待部署的儲存庫右側的 setting 按鈕，跳轉至 Travis CI 儲存庫設置頁。咱們須要在此頁設置部署 Github Pages 時所需的環境變量:
   

環境變量的值須要從 Github 拿擁有部署權限的 token:

1. 打開 Github，點擊頭像，再點擊 Settings 進入設置頁：
   
2. 進入設置頁面後在左側邊欄點擊開發者設置:
   
3. 跳轉後在左側邊欄點擊 Personal access tokens, 而後在頭部點擊 Generate new token:
   
4. 填寫 token 備註、權限，最後點擊生成 token:
   
5. 生成 token 後點擊複製按鈕，複製到粘貼板:
   
   注意要妥善保管好 token，從新刷新頁面後這個 token 將不會再展現出來。若是忘記了 token 的話，也只能在 token 編輯頁中從新生成。這會致使全部用到該 token 的應用都要更新值。 比方說有三個應用使用了該 token，從新生成後只在一個應用更新的值，那其餘兩個應用不更新就沒法使用了。
   
6. 複製 token 後切回 Travis CI 儲存庫的設置頁，添加環境變量:
   

這樣咱們的準備工做就完成的差很少了。

配置

在項目目錄中新建文件 .travis.yml，內容以下:

language: node_js
node_js:
  - lts/*

install:
  - yarn install # npm ci
script:
  - yarn test # npm run test
  - yarn build # npm run build

deploy:
  provider: pages
  local_dir: dist
  target_branch: master
  on:
    branch: develop
  token: $GITHUB_TOKEN
  skip_cleanup: true
  keep_history: true
  committer_from_gh: true

因爲 webpack 項目依賴 Node.js，所以語言(language) 設置爲 node_js，同時還指定使用最新的 LTS Node.js 版本(lts/*)。

install 是安裝部署所需的依賴項，script 則是用於運行測試或構建腳本。他們都是 Travis 的工做生命週期(Job Lifecycle)必觸發的鉤子(階段)。

install 鉤子如有腳本/命令運行失敗的話，整個構建會中止。而 script 鉤子表現則不一樣，當有腳本/命令運行失敗後雖然構建會失敗，但還會繼續執行後面的腳本。如 yarn test 運行失敗後會繼續跑 yarn build 命令。

如下是 Travis CI 主要的階段流程圖:

部署

經過 deploy 能夠指定部署方式，下面將逐個介紹部署所用的選項：

provider 是部署類型。如今咱們想將頁面部署到 Github Pages，那就須要將 provider 設爲 pages。

local_dir 指定要推送到 Github Pages 的目錄，默認爲當前目錄。webpack 默認的輸出目錄是 /dist，所以須要將值設爲 dist。除此以外，Travis CI 默認狀況下會刪除構建期間建立的全部文件，所以須要設置 skip_cleanup: true 保留構建出來的 dist 目錄.

若 on.branch 有 commit 提交的話，Travis CI 將從 on.branch 分支運行編譯腳本，編譯後會把 local_dir 目錄強制推送到 target_branch 中。(target_branch 默認值爲 gh-pages)

如今咱們要部署的儲存庫是 <username>.github.io。這種類型的儲存庫有些特殊——它只能在 master 分支展現構建後的代碼，而不能修改成其餘分支。在 GitHub 儲存庫的 Settings 中的 Source 選項能夠看到詳細信息:

然而其餘儲存庫則沒有這種限制:

所以要部署到 <username>.github.io 儲存庫的話，target_branch 只能設爲 master，觸發編譯的 on.branch 分支則能夠本身定義。

其餘儲存庫能夠按照標準流程來開發：

• develop 做爲開發分支
• master 做爲主分支
• gh-pages 做爲頁面展現分支

等功能開發並測試完畢後，將 develop 的代碼合併到 master 分支並推送至遠程。Traivis CI 檢測到 matser 有 commit 提交後會自動運行腳本構建，構建完畢後將輸出目錄推送至 gh-pages 分支。

固然 Github Pages 也不是隨便來一我的就能夠部署的，你想要部署到儲存庫中首先得有該儲存庫的操做權限吧？token 就是證實你身份的東西。在上文中咱們預先設置好了一個名爲 GITHUB_TOKEN 的環境變量，此處咱們能夠經過 $GITHUB_TOKEN 直接取出該環境變量的值便可。

其餘還有一些細節問題能夠調整：好比推送構建後的代碼到 target_branch 時使用的是強制推送(git push --force)，若是你以爲這種強制覆蓋歷史記錄的方式有點暴力的話，能夠設置 keep_history: true 來保留提交記錄。

自動部署後 commit 提交者默認是 Travis CI 的信息。也能夠設置 committer_from_gh 容許 Travs CI 使用令牌全部者的我的信息來提交 commit。

配置完畢後如今只需將 .travis.yml 提交到遠程，Travis CI 就開始工做了：

甚至還能夠在 Github commit 信息中看到編譯的狀況:

若是構建出問題的話，Travis CI 還會發郵件提示你:

部署成功後就能夠直接經過瀏覽器訪問啦~ 儲存庫部署的是 <username>.github.io 的話，訪問連接爲 https://<username>.github.io/。其餘儲存庫能夠訪問 https://<username>.github.io/<repoName>。

好比筆者的主頁與博客是兩個項目分離的，部署後的連接地址爲 https://anran758.github.io 和 https://anran758.github.io/blog。

參考資料:

• Creating a personal access token for the command line
• GitHub Pages Deployment
• Job Lifecycle

---

原文出自: webpack + Travis CI 自動部署項目應用