前端邁向 DevOps 之路(Pull Request Preview URL) 💪
前陣子終於有時間把理想中的 PR-preview link 整合起來，算是在 CI/CD 的整合上一個蠻大的里程碑。💪💪💪
像這樣，在 Pull Request 發出來之後，會跑 unit-test, end-to-end test，接著 mimi 機器人會回覆一個 comment，提供 preview URL 給 reviewer 確認。
為何這很重要？
以往的做法需要手動 checkout branch 下來，然後 build 完在 local 開啟做相關 review 及驗證，如果遇到相依的套件要重裝，那就會非常花時間。
如果每個 pr 都有一個可以執行的環境，可以提供 reviewer 更快速的檢視是否有任何問題，尤其前端的 UI ，有時候要測試許多不同的狀況，甚至各種 in App Browser 等等，就可以盡可能的讓大家集思廣益找到是否有其他可能產生的 side effect，這在多人協作開發時尤其重要。
不過這件事情說來簡單，但會根據 deploy 的複雜度而影響這件事情的難度。舉例來說，如果你的 ci 環境是只有一台 server ，那每次開個 pr 程式就會被蓋過去，因此傳統上來說是會根據 branch 來切環境。
像這樣： staging -> develop -> master ，只要任何一個 pr merge 回去就觸發 build，好處是有 QA/SDET 的話只要根據這幾個環境做測試就好。但這只能針對不同 branch 去做推版，還是離 PR preview URL 有段距離。
動態網址
因此如果要實現 PR preview URL，你的環境必須要支援動態網址吃不同的 branch 版本。以我們最後實現的例子來說：
- branch feat/SA-232-revise-cart-order 會發布到 https://feat-SA-232-revise-cart-order.weare.hiring.fakeurl
將 branch name 當作 subdomain ，讓 server 可以根據 subdomain 區分不同版本的程式。這部分的實作會根據你專案的技術架構有所不同，如果你的 deploy 環境是有 server side 的(PHP/Node/Ruby 等)，可以靠 nginx 來處理 subdomain 的 forwarding。
SPA + S3 + CloudFront Solution
不過如果你開發的網站是 SPA(Single Page Application)，用 S3 + CloudFront 可以完全不需要 server 就可以做到。
- 使用 S3 來 host 靜態網站，可以參考 Use S3 and CloudFront to host Static Single Page Apps (SPAs) 搭建你的環境。
- 接下來是重點：用一個 S3 bucket 來 Host 多個子網域內容(with Lambda@Edge)，可以參考 Host Wildcard Subdomain in One S3 Bucket(with Lambda@Edge)
Auto Reply bot:
環境都建置完成之後最後就剩下留言機器人啦，這邊以 bitbucket API 為例，簡單講就是先確認之前有沒有留過，沒有的話就留言 preview URL，有的話就更新留言並寫進更新時間。
這樣就可以啦。
小結：
大部分前端工程師還是喜歡刻畫面，玩 UI 玩 Libary，不過如果想要培養 DevOps 技能樹的話，蠻推薦從改善開發流程的各種地方著手的，除了可以加速自己團隊的開發速度，也是一個很棒可以練習的遊樂場。
推薦閱讀：
