如果你喜歡這內容的話幫我在 Twitter 和 Threads 上面分享給其他正在前端這條路上努力的朋友們，也別忘了訂閱我們電子報收到第一手消息喔 🚀
今天我們一個新的前端 app 做好了，我們需要把這個 app deploy 出去這樣才能讓使用者用到我們很辛苦完成的作品，但在 deploy 之前我們需要做一些準備來 monitor 和確保我們的 app 在 production 上面能正常運作
測試有分很多種，最常見包括單元測試和 end-to-end，你要說自己拿滑鼠和手機點一點這應該也算，我們總是需要一個方法可以確定我們寫的 code 是正確的被執行或是像 e2e 這種測試整個系統是否在正常運作，我們組還會弄一個 bug bash 就是請其他人一起照著 scenario 和 smoke test 測試新功能雖然我常常沒有去，我總覺得這類測試都能寫進 e2e 測試。
這些 unit test 也可以當作是 documentation 告訴你在什麼情況下這個 app 應該怎麼工作，也確保你的 app 在加入新功能後還會照著原本的方式跑或是提醒你是不是要更新測試了。
我們是上線之後我們有個 production test account 來做 smoke test，主要目的只是看最重要的功能或是 app 在 production 上面能不能跑起來畢竟若是電商我也不會真的在 production 下單買東西
我們 app 常常會用很多不同的第三方服務比如你如果需要有付款的功能可能會用 Stripe、需要 analytics 會有 google analytics、error tracking 服務會用 Sentry 等等，這些服務通常要怎麼搜集你傳的資料就是給你 API 加上你個人的 key 或是 token，有些人可能會根據 environment 不同而分不同的 key 或是基本的至少要知道你現在是什麼在 dev、staging、或是 production server，那這些並不會寫死在 code 裡面，version control 是有歷史記錄的所以不小心把 API token 存下來然後不小心這個 repo 是 public 的那有心人士就能把這 token 偷走了。
另一個寫環境變數好處是我們可以避免寫一堆 if else 來比較現在是什麼環境來替換我們的 API，算是某方面來說可以讓 code 更好看一點，那這環境變數可以寫在比如你最常用的 CICD 工具上這樣在 build time 時候他們會自動把存好的 secret 放進環境變數或是存進類似 AWS secret manager 的服務裡但這對前端可能用處不大。
當我們 app 寫完放上 production 後，通常你的 app 一定會在莫名其妙的時刻 crash 或是 not doing what you would like it to do，我們工程師雖然會隨著經驗越來越多去預測哪裡可能會報錯來做相對應的 error handling 比如加 error state 給使用者 feedback 、或是自動 retry 等等，不過我們還是需要一個方式來主動的讓 application 回報哪裡出錯了，所以才會有像是 sentry 、datadog 這些 error tracking 服務，大致上都是會在盡量不搜集使用者資料的情況下把重要的資料傳回來給我們 developer 看，最重要的當然是 error 和 stack trace 告訴我們說是什麼錯誤而錯誤怎麼發生的，是叫了一系列的什麼 function 最後導致這個 error，那通常 production 都會是 minify 過的所以如果你在 deploy 過程中有放 sourcemaps 的話這些第三方服務會幫你match然後給你source code or 幾乎是 source code，當然如果你把 sourcemaps 放在 production 上也行如果你確定不會有人拿這個攻擊你的 app 或是整個 app 抄走的話，聽說sentry有但我知道datadog 有 error replay 功能，這真的挺強大的他們用某種方式把 user 怎麼操作你的 app 用影片呈現給你讓你更方便的 debug。
這可能很多人知道甚至有些服務自動做了這個，在一個微服務的世界裡，一個 request 可能也會經過很多不同的服務最終才會回到使用者的電腦上，若你有在 header 上面打一個 uniqie 特別的 header 而且這個 header 會跟著 request 帶到下一個 service，你就可以把整個 user journey 或是確切一點說是 request journey 知道哪裡報錯或是跟哪個 service 拿資料等等
這些 error 也應該分等級才可以叫 oncall 的人來處理，比如被 throttle 了或是 SSR server 起不來等於沒有人能使用你的 app 那肯定要被通知然後修復
我們雖然在部署前會測試一下性能，well hopefully 你有，測試畫面渲染的速度、API response 的速度之類的，但我們不可能在世界各個地方用每個設備來測試，所以有個好的 performance monitoring tool 可以給你一個大概看看你的 app 在不同設備跑起來如何，像在 DataDog 裡面會給你各項 web vitals 平均值比如 LCP FID 等等，如果有什麼 KPI 或 OKR 需要達成比如 LCP metric P95 需要一秒之類的這邊也可以看也通常會有 logs 告訴你什麼 JavaScript 跑得慢或是圖片慢導致渲染慢。
對開發者來說我們會想要知道使用者是點了什麼做了什麼最後導致有 error，對 PM 或是 marketing 的人來說會想要知道使用者整個 journey 是什麼來判斷哪些 feature 是不是有人在用也可以利用手動 logging 來紀錄使用者的動作，主要目的不是要偷偷 track 他們的信用卡號碼或是密碼而是想知道你的產品和功能是怎麼被使用的，你可以配合 analytics 在你的 app 裡面做 A/B testing 最後看看哪個改動可以增加 conversion rate，你沒有完整的 logging solution 的話這些資料你很難搜集也很難幫你的產品做決定。
前端部署方式很多，根據公司文化選擇的技術都會有所不同，比如用 ftp 方式把檔案 copy paste、上 bastion server 把檔案更新不過現今時代應該很少人這麼做了，而且這種選擇檔案直接 copy paste 覆蓋的方式也會有 caching 問題，當 browser 已經 cache 這些檔案了而這些檔案路徑都一樣的話，只能等 browser 的 cache 過期了才會去抓新的檔案。
現在 build tool 也可以設定把產出來的 path 加上 uniqie hash 這樣放到 S3 bucket 或是用其他第三方 build tool 就不會產生部署後結果使用者還是拿舊的檔案導致出現 bug
延伸一點看如果你是用 SSR 框架你可能會用 Docker Kubernetes 幫忙做 deployment 和 auto scaling。
這些講的都是部署的方法，但今天萬一部署後發現有個 critical error 而且不是馬上可以知道出了什麼問題或是不好 hotfix，整個流程一定要有一個 rollback 的步驟以防萬一，就是說如果發布新版本結果出現很大的 bug，需要有個機制可以很快的返回到前一個版本，因為當下需要解決的事絕對是要讓網站正常運作而上一個版本知道可以正常運作。
這邊也給自己打廣告我有諮詢服務，想要了解更多前端職涯或是北美工作經驗、面試技巧、模擬面試都可以來諮詢，詳細可以看資訊欄的連結