Netlify — 靜態頁面的自動化部署神器
部署前端程式 — 在8102年來說，已經不是一件複製貼上、上傳這麼簡單的事情，在前端工程化的年代，一個單頁的網站專案可能有一拖拉庫的資料夾(src/ public/ config/ …)，但是最終User看到的只會是build完後的那個資料夾(docs/… 或是 build/…)，如果能夠自動化……
最終使用者只會看到那個 build 後的資料夾，我們可以很土炮的把 build 完的資料夾扔到 server 的 public_html 透過 apache 或其他的 web server 去 hosting ，不過這相當麻煩，每一次改動後 → build → cp 過去 overwrite ，當然這可以透過腳本解決，不過還是相當繁瑣。
先來說說GitHub — gh-pages
GitHub 本身有靜態部署的 Solution ，也就是 gh-pages ，也是筆者我一開始踏入瘋狂撰寫靜態應用的最大原因，它允許你將靜態應用的 repo 給 hosting 起來，且 URL 會是 https://${username}.github.io/${reponame}， User 可以一目瞭然的知道，這個靜態頁面的 repo 是來自何處，作為開源的Component而言，當然挺具備宣傳功能。
其中讓我感到挺方便的有兩點 —
- 方便的 CNAME 設定
- 直上 SSL
透過 Vue / React 撰寫的應用扔到 gh-pages 也會遇到一些麻煩的點：
- Vue / React 的 template 通常預設你的 Access 是從根目錄開始的，變成你要額外設定成相依 path ，比如 “/static” 得設定成 “./static” ，當然現在的 Vue ui 或是 React 的 config 都能輕鬆改掉 (publicPath之類的設定) 。
- 因為 master branch 拿來放置整個 repo ，所以只有兩個方法可以讓 GitHub 幫你部署應用 — (i) 把 build 後的path設定在 docs/ 的位置並 push 上去 (ii)將 build 後的資料夾另外 push 到 gh-pages 的 branch 。
關於第二點可以透過其他人撰寫的腳本去簡化它，例如這個。
再來說說我認為的神器 — Netlify
Netlify 承襲著 gh-pages 所擁有的優點，包括 CNAME 以及 SSL 自動上鎖，主要很狂的點：
- 持續性部署
- 沒有子路徑問題 — https://${app-name}.netlify.com/
- 支持 Private Repo
這邊開始依序講講這三點為何如此地 powerful。
持續性部署
如果各位有用過 CI/CD 工具，如Jenkins或Travis就知道持續性整合工具有多麼的方便，且 service 會持續 track 該 repo 是否有新的 commit 紀錄。
Netlify 目前支援的有 — GitHub / Bitbucket / GitLab，且會做到持續性部署，每當有新的 commit 上去，他會持續性地將靜態頁面給 build 起來。
沒有子路徑問題
如同Heroku，被部署後的程式可以自定義頁面名字，比如上面的 vue-tarot 這個 repo ，我把它定為 daily-tarot 這個名字，這樣子就可以透過 — https://daily-tarot.netlify.com/ 來 access 。
其 static file 就可以不改動原先規則、不使用相依 path 的方式直接 access ，雖然這點看似沒什麼，不過在調整 pwa 的 manifest.json 的 icon 位置時，真的會搞到難受、想哭、想扁人。
支持 Private Repo
這點我真心覺得非常屌，通常這類 CD 工具不會允許免費使用 private repo track ，不過 Netlify 目前是支援的，一些作為 demo 不打算開源的 project ，可以透過 Netlify 持續性地為新功能部署，無論是 demo 給親朋好友看、 demo 給案主看，我相信這都是一個非常棒的功能。
結論
雖然提了不少令人激動的點，不過筆者目前僅用過 GitHub 的 CNAME ，所以並不確定 Netlify 的 CNAME 開通時間啊、 SSL 狀況…，一個服務的穩定仍需要時間來考驗，但我非常非常的感謝有這樣的服務誕生於世界上，上一次有這種感覺的時候大概是第一次使用 Travis 了 :-P
