
TGONext: 追蹤和技術債
在 TGONext 期間我們基本上有 4 ~ 5 次的聚會,而這次算是表定上的最後一次聚會。在可能是最後一次的聚會,我們先討論了幾個原本沒有要討論的主題。
這次聚會中,我們會討論關於日誌追蹤跟如何處理技術債。
在 TGONext 期間我們基本上有 4 ~ 5 次的聚會,而這次算是表定上的最後一次聚會。在可能是最後一次的聚會,我們先討論了幾個原本沒有要討論的主題。
這次聚會中,我們會討論關於日誌追蹤跟如何處理技術債。
當我們的 Rails 專案邊複雜的時候,Form Object 算是一個常見的方法。不過網路上的教學似乎大多都沒有能夠相容 Rails 的 Form Helper 的版本。
所以我就開始思考,有沒有辦法法在比較少的修改下去支援 Form Helper 呢?
在幾年前我有一篇文章討論 Autoloading 的問題,這幾天剛好有同事在 Autoloading 和 Reloading 上也有類似的問題。
所以我決定寫一篇文章來複習 Rails 5 和 6 的 Autoloading 的機制。
這次在開始討論關於架構的主題之前,我們的倒是讓我們提出一些問題。
剛好在兩次聚會的期間,我的客戶因為一些錯誤的計畫讓 Migration 失敗了,所以我提出了關於在不停機的狀況下做 Migration 的規劃問題。
這次聚會我們先簡單的回顧一下上一次的討論,然後就切換到了下一個主題。基於前一次聚會高併發的討論,我們模擬一個簡單的架構然後開始演進。
因為時間的關係錯過了實體課程,不過利用 228 連假把工作上用得到的函數式程式設計這門課補完。
在 Functional Programming(函數式程式設計)裡面有許多概念是可以提取出來應用的,如果你使用的語言有支援一定程度的特性的話,就能更做出更多的變化。
包括我自己在內,寫測試有時候是一個非常不想面對的工作。也有很多剛入門的工程師覺得很難去分辨該怎麼去寫測試,在今天跟同事說明完一些技巧後就決定來寫一下這篇分享一下我自己的經驗。
去年雙十一活動的時候有一個算是比較急的專案是要做活動網站,當時評估了一下之後決定來嘗試透過 CI 自動生成 GCE 的自訂映像檔然後搭配 Auto Scale 來做部署。
會選擇這樣的方式主要是因為 Rails 或者大多數開發框架的部署工具預設大多是不適合 Auto Scale 的,像是 Capistrano 大多數是手動填入伺服器位置(之前也有實作過透過 GCP API 自動填入)比較適合雲端服務的作法其實就是是製作成一個映像檔來處理,也因此像是 Docker Image 這類型容器化技術在這方面是相對容易做的。
不過考量到容器化本身也還有一些調整問題才適合使用,再加上雲端服務的選擇是使用 GCP 來提供服務,並不像 AWS ECS 有專門針對容器的服務(可能是我不知道)而是提供 K8S 的方案,對一個短期活動來說在整個專案成員都沒有經驗的前提下學習成本還是偏高的。
因此相對適合的做法是用之前我準備好的 Ansible 腳本,搭配 Packer 這套工具直接在 GCP 上面生成一個自訂的映像檔然後直接更新 Instance Group 的設定讓他以新版本 Scale 起來,就能做到基本上網站不斷掉的更新(Health Check 和 Scale 規則需要調整好)
我們大概花了約一天多的時間快速搭起來,這次的開發時間約兩週中間是透過放額外的人力去支援搭建這個部署流程。