Google & Amazon 對於 CI/CD 的設計經驗談 https://carloarg02.medium.com/how-amaz… — 矽谷牛的耕田筆記

矽谷牛的耕田筆記@technologynote · 615 subscribers Open in TelegramOpen

矽谷牛的耕田筆記為什麼會有想要取代 Helm 後繼方案 https://itnext.io/finally-a-viable-helm-replacement-388d538f9e1f Helm 作為 Kubernetes 內最成熟且最多人使用的應用程式打包與發佈框架，這邊的應用程式代表的是用一堆 YAML 來描述的應用程式。 Helm 透過 1. 支援不同版本的設定與打包 2. 從早期的 www server 到後來的 OCI Server，有不同的方式可以發佈與讓人下載各種打包好的 Helm Chart (一整包…

Google & Amazon 對於 CI/CD 的設計經驗談
https://carloarg02.medium.com/how-amazon-and-google-view-ci-cd-in-an-entirely-different-way-824b9c36777e

作者過去 20 多年內，先後待過 Amazon, Google, Amazon(回鍋) 內關於 CI/CD 的相關部門。
作者透過自身的經驗觀察到這兩家大公司對於 CI/CD 的設計哲學是截然不同的，而這個截然不同主要體現於
1. Pre-Summit: 程式合併前的各種操作
2. Post-Summit: 程式合併後的各種操作

以經驗來看， Google 的 Pre-Summit 做得非常完善，而 Amazon 則是 Post-Summit 更為完善。

作者認為造成這兩種近乎對立截然不同的結果的成因在於程式碼的架構。
Google 採取的是超級 monorepo，全公司的程式碼都放到一個共同的 Git Repo，所有改進都會曠日廢時，以作者當年的經驗來說，部署一個應用程式到 Production 可能是幾天後。但是也因為這種框架，使得 Google 非常專注設計 Local Dev Environment 的設計，所有開發者都要有辦法能夠於本地進行完整的 E2E 測試，確保測試完畢後才有機會合併到最終的 Repo.

與之相反的是 Amazon 則是各種 microrepo 的概念，應用程式散落到不同的 Git repo 中，每個都有自己獨立的開發與部署流程，彼此之間互相不干擾，因此 Production 的部署也不會被其他人影響，速度很快，但是相反的是 Pre-Summit 前的操作則是因為整個 E2E 牽扯過多的 Repo，導致設計上變得困難。

作者以自身的經驗來想，並沒有覺得兩個解決方案是絕對勝利的，畢竟 Google & Amazon 兩者也都走到了今天，公司也還在繼續成長茁壯，軟體的發展也是一直持續前進，與其說某種架構是絕對正確的，不如說每個環境有適合的架構。