在 Web JavaScript Infra Team 的工作紀錄
緣分就是那麼奇妙，在進入 LINE Taiwan 以前，我寫了「雜談系列 — Web Frontend Infra」這篇文章，對於有些企業會成立一個專門處理 Web JS Infrastructure 的團隊感到非常認同與感興趣，這個團隊的工作內容並不侷限在前端，而是 JavaScript 這個程式語言的開發生態系，當然啦，大多數題目還是跟前端開發比較有關聯就是了。而在進入 LINE 不久後，我才從主管那得知 LINE 不久前也才剛成立這樣的團隊，衡量 LINE Taiwan 的團隊規模以及量級，有這樣的團隊理應可以減緩開發與維護大量專案時的複雜性與不一致性，同時也可以大幅優化開發者體驗（關於 JS Infra Team 可以帶來的優勢可以參考上方的文章連結）。有這麼好的機會我當然不想錯過，就非常厚臉皮的以 Junior Developer 的身份加入了（其他成員都是資深的開發者，老實說一開始壓力有點大，不確定自己可以貢獻什麼😂）
因為自己有定期回顧在工作上經歷了哪些事的習慣，剛好這陣子工作上的快樂來源與成就感都來自於做 JS Infra 的任務，就想說透過一篇文章紀錄一下在加入 JS Infra Team 後自己完成了哪些事項吧！
其實 Infra Team 的任務非常多元，像是制定各專案間統一的開發準則或是開發共用的工具都包含在內，今年 10 月我在 MOPCON 研討會的議程中也有快速介紹了 JS Infra Team 迄今為止做過的事項，有興趣的人可以參考我在 MOPCON 議程的簡報。其中很多事項是在我加入前就已經導入了，我就不一一敘述了，這篇文章主要會紀錄自己加入後有實際參與的任務。
ESLint Config For SonarQube Rules
這是我加入 JS Infra Team 後的第一個任務，主要就是開發一個給各個專案共同使用的 ESLint Config，不過比較特別的是這個 config 要包含的 rules 並不是常見的 TypeScript、React 等等的 linting rules，而是我們希望在 linting 階段就能掃出一些 SonarQube 這個程式碼品質管理平台有可能會報錯的寫法（我們有在 CI 流程裡導入 SonarQube 檢測並定期追蹤程式碼品質狀況），所以這個 config 主要是收錄了 SonarQube 對於 JavaScript 與 TypeScript 所制訂出的 rules，希望能更早的避免 commit 會讓 SonarQube 檢測出包含 code smells 或潛在 bugs 的寫法。
Lighthouse CI Integration
這也是我在今年 MOPCON 議程上主要分享的主題，至於導入專案的過程之前也寫過一篇文章「整合 Lighthouse CI 時遇到的大小事 feat. MSW & Drone CI」，有興趣的人可以再去看看。
有趣的是當時我發現我們內部一個計算 Lighthouse 相對分數並留言到 PR 上的 npm package 在行為上有些 bug，有時候沒辦法與正確的分支上正確的 commit 做分數的比對，自己花了一些時間研究 LHCI API 後才修正了這個 package 的 bug。
透過這次的經驗我也接觸了 GitHub API，後來發現它對 JS Infra Team 的很多任務都有很大的幫助，多了很多提升開發者體驗的機會（後面幾個項目都可以看到有使用它）。另外我也很開心可以將這次對於 Lighthouse CI 的研究經驗到技術年會上分享給更多人，對我而言是一個相當難忘的經驗。
Grafana Dashboard For Monitoring
以 Frontend 的專案來說一般會搭配 Sentry 或是 Google Analytics、Google Search Console 等可以觀測錯誤、使用者流量、Web Vitals…等等指標的 tracking system，較容易找出網站可以加強或修改的地方。不過除此之外，JS Infra Team 有另外建立一個 Grafana 的 Dashboard，用來觀測各專案近期by PR 的 testing coverage、code smells 數量…等等，未來也會持續豐富這個 dashboard 的內容。
其實我加入團隊時這個 dashboard 就已經被建立好了，不過我曾經為了解一個 dashboard 上資訊不正確的問題，也去研究了一下 Prometheus 的 query 要怎麼寫，算是蠻特別的經驗。
題外話，講到 Frontend Application 的 Observability，未來我應該會去研究一下 Grafana 近期才推出的 Grafana Faro，我自己認為會是未來處理 Frontend Observability 很重要的工具。
Generator
大家一定都用過 create-next-app或是 create-react-app等 CLI 工具，可以透過一行指令快速建立一個包含許多 basic template 的專案。而 LINE Taiwan 前端的專案雖然很多都是透過不同的 frameworks 撰寫的（例如有的專案用 Vue，有的則用 React），但是對於未來的新專案，則是希望可以統一技術堆疊為 NextJS + TypeScript。然而剛剛也提過 JS Infra Team 制定了一些統一的開發準則，例如導入 SonarQube、導入 Lighthouse CI，如果每個新專案在建立時都需要手動去設置這些標準，相信是非常麻煩的，所以 JS Infra Team 決定建立一個類似於 create-react-app的 generator，可以透過一行 CLI 指令就建立出符合統一技術堆疊 (NextJS + TypeScript) 又包含一些共同準則的 basic config （例如 SonarQube 的基本設定檔）的全新專案，希望可以用這種方式降低每個專案建置初期的複雜度與耗時。
這是我第一次參與這種專案建置工具的開發，是一個難得的體驗，也激發出自己未來想打造更多這種可以加速開發流程的工具的渴望。
DAST ZAP Security Scan
這個主題之前也寫過一篇文章介紹了「在 CI/CD pipeline 中加入安全性檢測吧！」，有興趣的朋友也可以再去逛逛。不過後來又進一步做了一些功能，例如把 scan 後的 report 上傳到類似於 AWS S3 的儲存空間中（會說類似是因為我們內部有自己開發類似 AWS 的雲端服務平台），並且回推到 PR comment 裡，理想的狀況可能不需要整合到日常開發的 CI Pipeline 中，而是在 sprint 結束要 release 前可以去做一次檢測看看是否有重大的安全性問題（例如在 CI Pipeline 中指定只有 RC branch 要執行 ZAP scan 的 step）。
Preview URL
這是還在進行中的任務，主要是以前實習的時候的主管有成功導入 Preview URL (參考連結)，可以在每次發 PR 或是在 PR 中有新的 commit 時都會自動部署一個版本並提供 URL 給進行 code review 的工程師或是 QA 工程師測試。我認為這是一個可以大幅優化開發流程的工具，因此在一次與主管 1 on 1 時提出這個想法，沒想到最後就真的進入團隊的開發任務中了。（順帶一提，像 Vercel 等平台其實已經有提供完整的 Preview URL 方案，但在規模比較大的公司中通常是不能隨意使用第三方服務的，很多流程都得自己架設。）
不同於上面的參考連結採用的方法是將 React SPA build 後的結果上傳到 S3 host，因為我們是使用 NextJS 的 SSR framework，只靠 S3 是不夠的，需要手動起一個 Server 來 host 專案。目前我們跟 SRE Team 合作與討論後主要的流程是在發 PR 或是 commit 時都會去 trigger 一個部署流程，URL domain 會使用 ${機構名稱}-${專案名稱}-${PR Number} 組合而成，再透過 GitHub API 將部署後的 URL 留言回到 PR 中。因為需要在 PR 關閉時釋出部署的資源，我們初步是希望透過 Probot 這個可以監聽 PR 事件的工具來開發相關的流程，因為目前還在開發階段，所以關於 Preview URL 這個功能的紀錄只能停在這裡，如果未來功能完成後我會再更新這個段落。
小結
加入 JS Infra Team 後自己最大的收穫就是找到自己在前端開發裡最喜歡的領域。我們都知道在前端開發這個領域主幹裡可以延伸出很多不同的分支，例如專精於打造充滿互動式與精美動畫的網頁、專精於 3D 技術…等等。對於不喜歡刻畫面的我來說，打造給開發者使用的工具、優化 Pipeline、效能、監控…等等主題反而是我非常有興趣的，很開心可以在 JS Infra Team 學習與嘗試一些自己有興趣的技術，希望未來可以碰到更多有趣的任務！
