過去，Psono.com 是由 Odoo v11 驅動的。Odoo 是一款出色的 CMS，但我們不得不承認，升級是一件很困難的事情。特別是當我們在測試時，他們的網站模塊帶來了很多麻煩。Odoo v11 將在 2020 年底達到生命週期末期，因此我們必須找到一個解決方案。
我們考慮了不同的選項，要麼升級到 Odoo v13 並手動遷移所有內容和自定義設置，要麼聘請人幫助我們進行遷移，或者完全遷移到新的 CMS。我們決定完全從 Psono.com 遷移出去，並將繼續在防火牆後使用 v11，稍後再進行遷移（我們還未決定）。
做出此決定的原因是：
- 我們只有很少量的內容需要遷移到 Psono.com。主要是一些部落格文章。
- 遷移到 Odoo v13 會在兩年後同樣面臨問題，當 v13 達到生命週期末期時，可能需要遷移更多數據。
- 我們對 Odoo v11 網站的自定義能力不滿意。由於模板存儲在數據庫中，一切都顯得非常複雜。
- 成本。聘請人來做遷移至少需要花費我們 5000 美元，可能更多。
- 儘管 Odoo 的社群非常活躍，但隨著最近幾年許可轉換以及功能和插件遷移到付費解決方案，並將所有東西放在付費牆後面，社群變得活躍不再。
- Psono.com 主要是一個靜態網站，具有靜態內容。如果我們需要動態內容，可以通過 API 獲取。
過程
在決定遷移之後，我們需要決定選擇哪種框架。雖然我們用過例如 Hugo 這樣的經典框架，但其功能有限。在尋找替代方案時，我們發現了一些來自 Node / React 世界的解決方案。
我想在這裡寫下「優秀的解決方案」，但我不認為目前前端開發的崩潰狀態值得這樣的稱號。你是否覺得崩潰？還記得以前開發者可以通過 index.html 和 script 標籤加載 jQuery 開始開發網站的時候嗎？現在你需要 npm 或 yarn，需要了解 package.json、webpack 腳本、現代框架如 Angular 或 React，它們都自帶客戶端。JSX 或 TypeScript。像熱重載這樣的功能也不可靠（文件沒被監控，一些修改需要完全重啟，或者熱重載過早觸發因此仍需手動刷新）因此你最終會終止開發服務器並等待幾分鐘重新啟動（至少在較大項目中）。（我懷念直接按 F5 就能一切正常，沒有任何問題的時候！）更不用說每半年就有新框架或工具出現，舊工具每天被棄用。要是讓我抱怨前端開發的現狀，可以輕鬆寫下許多頁面。不過，還是回到正題。
在缺乏合理替代方案的情況下，當時最好的選擇是 next.js 和 gatsby。至少有一些文章是這樣宣傳的。如果比較 GitHub 星數或提交次數，二者同樣受歡迎。我們在最初評估中發現的唯一區別是 next.js 需要服務器組件，而 Gatsby 可創建靜態網站（如果 next.js 有無需伺服器的選項，請別攻擊我！ :D）
所以我們嘗試了一下 Gatsby，感覺不錯。接下來，我們尋找了一個主題。Gatsby 是一個「新」工具，因此我們找到的所有主題都還處在非常基礎的狀態。三十分鐘和三十美元後，我們得到了視覺上吸引人的主題，至少覆蓋了部分需要的組件，然後開始進行修改。
現在的託管選擇眾多，包括 Firebase、Netlify、Cloudflare、Vercel、簡單的 GCP 雲存儲或 AWS CloudFront、自有服務器、運行在 Kubernetes 上的 Docker 容器（不得不提到它！）……（還記得以前用 $5 一個月租一個帶 PHP 和 MySQL 的網頁空間的時代嗎 :D ……但這是另一篇文章的題材了……）
經過比較，閱讀評論，查看可能的組合（如 Cloudflare 前置 Firebase）後，我們最初嘗試了 Cloudflare。作為其服務的忠實粉絲，這是自然而然的選擇，但很遺憾，他們的 Wrangler 工具有問題。首先它總是拋出錯誤，我們無法進行身份驗證……初步錯誤消失了（可能一個新的 bash 起了作用），但身份驗證問題依然存在。我相信我一定犯了某種錯誤，在讀了幾個小時文檔並嘗試不同解決方案後放棄了。
Netlify 是另一個候選者，但你要麼必須將它連接到一個 git 提供商並讓他們構建（我們計劃使用 GitLab CI），要麼手動上傳構建輸出。他們可能有一個選項允許通過 API 上傳構建輸出，但我沒找到。另一個選擇是建立一個實際上推送構建輸出的 repo，但這看起來過於複雜……另一個問題是他們的定價模式。每位成員（!!!）收取相當可觀的金額。請記住，這是為了一個靜態網站。像「4× 帶寬」這樣的聲明讓我想起了「公平使用網頁託管」時代的惡夢，當時如果你使用太多，他們會踢掉你。
第四個服務我們嘗試了 Firebase（可以免費使用，滿足我們的目標帶寬和請求），一切都開箱即用。他們的重定向功能有些限制，將舊網址映射到更美觀的網址變得有些乏味，但幾條重定向規則後一切都運行良好。他們的定價看起來比較合理，你只需為伺服器資源付費。我們應該避免所有的額外服務，以避免供應商鎖定，但我們只需要託管服務。
我們也簡單查看了 Vercel，但他們要求用 Github 賬號登錄，然後是一個帶有「代表我行事」的權限，這在註冊之前就讓我望而卻步。
部落格是最難遷移的。我們最終手動複製了所有內容。這不是一個大規模部落格應該做的，但我們的部落格只有十五篇文章。Gatsby 支持多種機制，但我們想要的是樣一個簡單的方式，可以讓沒有技術背景的人創建新的部落格文章。我們決定使用 Markdown，因此必須學習如何指導 Gatsby 閱讀 Markdown 頁面。整個機制，包括圖像處理，花了我們大約半天。在美化部落格主題及圖像後又花了半天。
在遷移所有內容並進一步強化主題後，我們用 GitLab CI 自動化了我們的部署，因此簡單的推送就會觸發我們的構建流水線，將所有內容部署到 Firebase。
為什麼選 GitLab 而不是 Github？GitHub 由於歷史原因占據領先地位。他們目前擁有至少 80% 的開發人員和項目。GitLab 方面則提供了功能。因此在過去，我們選擇了 GitLab，因為 GitHub 在產品功能開發上多年沒有實質進展。這一點隨着 Microsoft 收購了 GitHub 而發生了戲劇性色變。GitHub Actions 是一個里程碑，但若要與 GitLab 競爭，GitHub 還有很長的路要走。因此，對於我們這些將所有項目都託管在 GitLab 上的人來說，將其用於這個項目也是自然而然的選擇。
結論
現在情況是這樣的：
- 使用 Gatsby 作為 CMS
- 商業主題
- Markdown 驅動的部落格
- 使用 Gitlab CI 進行自動化部署
- 使用 Firebase Hosting
我們對這個結果感到非常滿意，新網站看起來好多了！
