當說到自動部署的時候，我很反感那些一上來就balabala說怎么操作的博文文章，照着別人的做法有樣學樣，經常會因為與自己項目實際情況不符而出現各種問題。
比如說github和travis，首先應該搞明白，他們之間是如何運作的。
首先，github pages是集成在github里面，可以解析靜態的文件，並渲染成頁面的。所以最簡單的github pages應該是這樣，新建一個項目，項目里面包含一個index.html。在項目的settings中打開github pages。搞定！
但問題是，我們很多的實際項目，比如vue-cli項目。不是一開始就有靜態文件的，而是需要手動通過npm run build或yarn build來打包生成。可能有人會說：我本地可以配置靜態文件的導出目錄，將靜態文件導出到github pages能識別的路徑。比如根目錄或者根目錄下的docs文件夾，在本地先run build，然后再把靜態文件push到github上，供github pages解析渲染。
但如果要弄成這樣，還叫自動化部署嗎？還叫持續集成交付嗎？所以問題的關鍵是：需要找到一個東西，可以幫我們run build，同時生成的靜態文件也要放在github pages可以解析的路徑里。程序員每次推代碼只關心代碼本身，不關心打包過程和靜態文件應該存放在哪兒。
github本身是沒有這個環境來run build的，誰有呢？travis有。
所以他們的運作過程是這樣的：程序員往github上推了代碼 --> travis檢測了到程序員這一行為 -->拉取最新的項目代碼到travis --> 在travis的虛擬機中對這個項目進行run build --> 生成靜態文件 --> 將靜態文件傳回給github的可識別目錄，供github pages解析渲染。
說得直白一點：你推了項目到github上，travis把你的項目給克隆過去了，然后在travis的小黑屋的幫你打包靜態文件，最后送還靜態文件到你的github上。
搞清楚了運作原理，接下來才是一些實施細節。
1，travis怎么知道程序員推了代碼到github?
travis與github是一對好基友，在travis的社區級官網（https://travis-ci.org/）里，可以用github賬號登錄，登錄之后，即代表你的github對travis進行了Oauth授權，travis可以訪問你的所有項目列表，同時，只要你手動打開監聽開關，travis就可以監聽指定項目的活動狀態，比如有沒有推代碼。
2.監聽到了github活動之后，諸如克隆代碼，run build，返還靜態文件這些操作細節在哪里配置？
在github項目的根目錄下新建一個.travis.yml的shell腳本文件，當travis監聽到github項目活動時，就會在項目的根目錄下找這個腳本文件，如果找到了，就執行文件里的內容。由於travis跟github是好基友，並不需要在你的項目中安裝其他什么雜七雜八的東西來支持.travis.yml,直接新建即可。但注意必須嚴格起這個名字。下面是一個vue-cli項目的詳細注解的shell腳本文件。
源碼如下：
language: node_js
node_js: '11'
branches:
only:
- master
git:
quite: true
depth: 1
submodules: false
cache: yarn
install: yarn
script: yarn build
deploy:
provider: pages
keep-history: true
skip-cleanup: true
github-token: $GITHUB_TOKEN
local-dir: ./dist/
on:
branch: master
3.travis對github項目的讀寫操作需要授權，如何授權？
在github/settings/developer settings/personal access tokens中，新建一個token，如下圖：
除了不准travis直接刪掉我的github項目，其他的權限我都給了。生成之后在travis-ci.org中打開指定項目的settings，將token復制到到項目的環境變量中，並給他取個名字，如下圖：
比如我取的名字是GITHUB_TOKEN，那在.travis.yml執行的腳本里，通過$GITHUB_TOKEN就可以拿到這個授權碼。
4.放到指定github路徑中供github pages解析，那哪些路徑才是有效的？
在github的項目的settings中，可以看到pages一欄，可以看到合理的解析路徑一共有以下幾種：
在這里我們選擇第一種，為什么是gh-pages分支？因為travis在向github返還打包好的靜態文件時，travis也是非常擔心怕覆蓋掉程序員寫的代碼，所以往master分支推還是往其他什么dev、develop、test分支推，只要是程序員自己建的分支，都有風險。這時候就需要有一個特定分支，這個分支不需要程序員自己建，而是travis來建，並且里面只存放靜態文件，專門用於供github pages解析。這個travis默認新建的分支名，就叫gh-pages。在我的github項目中點開gh-pages分支，也可以看到這個分支的操作者是travis而不是我。
5.travis ci跑完后頁面靜態資源無法加載，報404錯誤？
這個問題屬於vue-cli項目的打包配置問題了。默認情況下，Vue CLI 會假設你的應用是被部署在一個域名的根路徑上，如https://www.apps.com。如果應用被部署在一個子路徑上，你就需要用這個選項指定這個子路徑。例如，如果你的應用被部署在 https://www.apps.com/my-app/，則設置 publicPath 為 /my-app/。所以要在vue-cli3.x項目的根目錄下，新建一個vue.config.js文件配置一下publicPath。
當然可以用“./”相對路徑來實現，不過相對路徑在一些場景中會有問題。比如當使用基於 HTML5 history.pushState 的路由時，或者當使用 pages 選項構建多頁面應用時。所以還是不要用相對路徑這種投機取巧的方法。在完成這一系列操作后，可以看到最終效果：一個vue-cli項目的默認界面。
