用 Travis CI 自動部署 Github Pages

原文連接：用 Travis CI 自動部署 Github Pages

前言

Github Pages 不能運行動態程序，只能輸出一些靜態內容。所以 Github Pages 很是適合用於前端項目的展現。可用於存放項目介紹、項目文檔或者我的博客。本文介紹了怎麼用 Travis CI 自動化部署 Github Pages。

關於 CI

持續集成（Continuous integration）是一種軟件開發實踐，即團隊開發成員常常集成他們的工做，一般每一個成員天天至少集成一次，也就意味着天天可能會發生屢次集成。每次集成都經過自動化的構建（包括編譯，發佈，自動化測試）來驗證，從而儘早地發現集成錯誤。目前 github 開源項目用的較多的 CI 主要是 Circle CI 和 Travis CI，二者都是利用容器技術來適配不一樣項目環境。

(圖一 CIrcle CI，圖二 Travis CI)

步驟

1. 安裝 Github App

在 Github Market Place 安裝 Travis CI。安裝時選擇你想要的項目權限。
<img src="https://s2.ax1x.com/2019/05/0...; width="50%" alt="ENCylT.png" title="ENCylT.png" />

2. 配置 Github Token

配置 Github Token 用於 Travis CI 對你項目的訪問權限，配置完了以後 不要刷新頁面，先點一下 Token 後面的複製按鈕，由於你只能看見這個 Token 一次，刷新了它就沒了 不得不讚一下 Github 的安全性 :+1:

3. 加密 Github Token

如下是 Travis CI 官方文檔的 Github Pages 配置示例：

deploy:
  provider: pages
  skip_cleanup: true
  github_token: $GITHUB_TOKEN # Set in the settings page of your repository, as a secure variable
  keep_history: true
  on:
    branch: master

$GITHUB_TOKEN 是加密後的環境變量。若是不加密直接提交明文到一個 Repo 的話，github 會直接刪除掉這個 token，簡直太安全了 加密步驟爲

gem install travis      # Travis CI 官方 cli 工具
travis login --pro      # 登陸 Travis CI ，帳號密碼爲你 Github 的帳號密碼
travis encrypt 'GITHUB_TOKEN=<YOUR_GITHUB_TOKEN>' --add     # 加密 github token 並自動添加至配置文件

4. 配置 .travis.yml

完整的 .travis.yml 配置示例，須要將前面加密的 github token 解密，固然只有 Travis CI 知道解密後的結果是啥

地址：Bougie Design Travis CI config

language: node_js
node_js:
  - '10'
before_install:
  - composer config --global github-oauth.github.com "$GITHUB_TOKEN"
install:
  - yarn
test: true
script:
  - yarn docs:build
  - cp -r ./.docz/dist/* .
deploy:
  provider: pages
  skip_cleanup: true
  github_token: $GITHUB_TOKEN
  keep_history: true
  on:
    branch: master
env:
  global:
    secure: TTQLIDz0jL4FRFrpq6DDocxLiELUSpJsj9phdmjW9Eg9kna73KjPF2XmZaWFvkObZU3og/7Thr/iwsXQqfdq8gHShhLkHZAZqgvWqbjMIQABYIFqqqUE9grrPdrLXWVAidh+nET+pjes8VX92NBz6HA+i/15+PugVwYhC85AGyNN2JRL7nxCwh2ECiKATRiX+cLmVqFwTGpzqHovAiBFnap17whWa4C4uVEzdBwjQAZKw+IFxiiJIA7hkFTTThS11uCx//Dr7/A1X7c6ZLao/qiwvW8fNAbhV5ZA6dx4a0vtLwj6lprjcwWuGQX/vutKHnpdNpxeIDhmLNspN1U7YxjgUZJXgFjpE6tw1I8N6nSRpzhPUlrXPkKUAdN9x2jN20NSUeFDSl0FhazPwhGWzlSQb0gNyH1U04wvw3QB2VP/3UvTiyCZjum6prTpuXy/D262smG97o0/0XlNySX6MC+OLQNDIVgzO4YO2IHVB8lW6CBSMeTlcE8a4yvHwmGQpLKnX6tY06/n8lvjgZgPKZaRZL6aVrBE+/104Gt/aBFpraZZpiXJjXjdm4TO3N+u8gT8+gkDJ0BvzrX7Kf/W/WouecziCJgzYCB7y8eqec4kmZKRs2O6zyKJ0SbPrW54UuCmjFzTLEmdRCXRLIbEQsWvS5x+FKKwGNGRcrgPjxY=

5. 觸發 CI

通常默認是 git push 時觸發，也能夠修改爲 tag 時觸發，push 後能夠到 travis-ci.com 查看 CI 日誌。若是出現下圖所示日誌，則代表部署 Github Pages 成功了
<img src="https://s2.ax1x.com/2019/05/0...; width="50%" alt="ENzmkt.png" title="ENzmkt.png" />

6. 查看 Github Pages

Travis CI 會自動建立一個叫 gh-pages 的分支，如圖所示：
<img src="https://s2.ax1x.com/2019/05/0...; width="50%" alt="ENz8mj.png" title="ENz8mj.png" />

到項目設置中設置 Github Pages 分支爲 gh-pages：

訪問 https://your-github-id.github.io/repo-name/ 便可訪問 Github Pages 了。須要注意的是 Github Pages 的 root path 不是 /，而是 /repo-name/，所以在打包時記得把基礎路由設置成 /repo-name/，不然會出現資源路徑錯誤的狀況。

附：阮老師對幾個「持續「概念的解釋

1、概念

持續集成（Continuous integration）指的是，頻繁地（一天屢次）將代碼集成到主幹。

它的好處主要有兩個。

（1）快速發現錯誤。 每完成一點更新，就集成到主幹，能夠快速發現錯誤，定位錯誤也比較容易。

（2）防止分支大幅偏離主幹。 若是不是常常集成，主幹又在不斷更新，會致使之後集成的難度變大，甚至難以集成。

持續集成的目的，就是讓產品能夠快速迭代，同時還能保持高質量。 它的核心措施是，代碼集成到主幹以前，必須經過自動化測試。只要有一個測試用例失敗，就不能集成。

Martin Fowler 說過，"持續集成並不能消除 Bug，而是讓它們很是容易發現和改正。"

與持續集成相關的，還有兩個概念，分別是持續交付和持續部署。

2、持續交付

持續交付（Continuous delivery）指的是，頻繁地將軟件的新版本，交付給質量團隊或者用戶，以供評審。 若是評審經過，代碼就進入生產階段。

持續交付能夠看做持續集成的下一步。它強調的是，無論怎麼更新，軟件是隨時隨地能夠交付的。

3、持續部署

持續部署（continuous deployment）是持續交付的下一步，指的是代碼經過評審之後，自動部署到生產環境。

持續部署的目標是，代碼在任什麼時候刻都是可部署的，能夠進入生產階段。

持續部署的前提是能自動化完成測試、構建、部署等步驟。它與持續交付的區別，能夠參考下圖。

（圖片來源）

4、流程

根據持續集成的設計，代碼從提交到生產，整個過程有如下幾步。

4.1 提交

流程的第一步，是開發者向代碼倉庫提交代碼。全部後面的步驟都始於本地代碼的一次提交（commit）。

4.2 測試（第一輪）

代碼倉庫對 commit 操做配置了鉤子（hook），只要提交代碼或者合併進主幹，就會跑自動化測試。

測試有好幾種。

• 單元測試：針對函數或模塊的測試
• 集成測試：針對總體產品的某個功能的測試，又稱功能測試
• 端對端測試：從用戶界面直達數據庫的全鏈路測試

第一輪至少要跑單元測試。

4.3 構建

經過第一輪測試，代碼就能夠合併進主幹，就算能夠交付了。

交付後，就先進行構建（build），再進入第二輪測試。所謂構建，指的是將源碼轉換爲能夠運行的實際代碼，好比安裝依賴，配置各類資源（樣式表、JS 腳本、圖片）等等。

經常使用的構建工具以下。

• Jenkins
• Travis
• Codeship
• Strider

Jenkins 和 Strider 是開源軟件，Travis 和 Codeship 對於開源項目能夠無償使用。它們都會將構建和測試，在一次運行中執行完成。

4.4 測試（第二輪）

構建完成，就要進行第二輪測試。若是第一輪已經涵蓋了全部測試內容，第二輪能夠省略，固然，這時構建步驟也要移到第一輪測試前面。

第二輪是全面測試，單元測試和集成測試都會跑，有條件的話，也要作端對端測試。全部測試以自動化爲主，少數沒法自動化的測試用例，就要人工跑。

須要強調的是，新版本的每個更新點都必須測試到。若是測試的覆蓋率不高，進入後面的部署階段後，極可能會出現嚴重的問題。

4.5 部署

經過了第二輪測試，當前代碼就是一個能夠直接部署的版本（artifact）。將這個版本的全部文件打包（ tar filename.tar * ）存檔，發到生產服務器。

生產服務器將打包文件，解包成本地的一個目錄，再將運行路徑的符號連接（symlink）指向這個目錄，而後從新啓動應用。這方面的部署工具備Ansible，Chef，Puppet等。

4.6 回滾

一旦當前版本發生問題，就要回滾到上一個版本的構建結果。最簡單的作法就是修改一下符號連接，指向上一個版本的目錄。