これまで Psono.com は Odoo v11 により運営されていました。Odoo は素晴らしい CMS ですが、更新が難しいことを学びました。特にウェブサイトモジュールはテスト中に多くの問題を引き起こしました。Odoo v11 は 2020 年末までにサポート終了となるため、解決策を見つける必要がありました。
私たちはいくつかのオプションを検討しましたが、Odoo v13 にアップデートしてすべてのコンテンツとカスタマイズを手動で移行するか、専門家に依頼するか、まったく新しい CMS に移行するかの三択でした。最終的に、Psono.com を完全に新しい CMS に移行し、後でファイアウォールの背後で v11 を使用し続けることにしました。（まだ決定していません。）
その決定に至った理由
- Psono.com に移行する必要のあるコンテンツはごく少量でした。主にいくつかのブログ記事程度です。
- Odoo v13 に移行しても、2 年後に v13 が EOL に達した際に同じ問題が再発する可能性があり、移行するデータが増える可能性があります。
- 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 は「新しい」ツールであり、見つけられたテーマはまだ非常に基本的な状態でした。30 分と 3 ドル後に、少なくとも必要なコンポーネントをカバーする視覚的に魅力的なテーマを手に入れ、それを改良し始めました。
ホスティングオプションとして、現在では Firebase、netlify、Cloudflare、Vercel、簡単な GCP Cloud ストレージや AWS Cloudfront のほか、自分のサーバー、Kubernetes 上で動作する Docker コンテナ（これも言及しました！）など、複数のプロバイダーから選べます。 （昔ながらの PHP と MySQL DB 付きの 5 ドル/月のウェブスペースとは違いますが、それはまた別の記事で...）
比較検討し、いくつかのレビューを読み、可能な組み合わせ（例えば、Firebase の前に Cloudflare を置く）をチェックした後、最初に Cloudflare を試しました。彼らのサービスの大ファンとして、自然な選択でしたが、残念ながら wrangler ツールに問題がありました。最初は常にエラーを投げ、認証ができませんでした。翌日には最初のエラーは解消しました（おそらく新しい bash が効果を発揮した？）、しかし認証の問題は続きました。数時間にわたるドキュメントの読み込みと異なる解決策の試行の後、あきらめました。
Netlify も候補でしたが、Git プロバイダに接続してビルドさせる必要がありました（GitLab CI を使用したかったので）、ビルド出力を手動でアップロードする必要がありました。おそらく API を通じてビルド出力をアップロードするオプションがあるかもしれませんが、見つけられませんでした。代替案としてビルド出力をプッシュするリポジトリを設定することも考えましたが、それは不必要に複雑に思えました…別の問題は彼らの料金体系です。メンバーごとにかなりの金額を課金されることです。これは静的なウェブサイトのためのものであることを念頭に置いてください。「4× 帯域幅」といった記述は「フェアユースウェブホスティング」の悪い記憶を呼び起こし、使いすぎると追い出されるかもしれない...
四つ目のサービスとして Firebase を試しました（目標帯域幅とリクエストに対して無料であるという利点があるため）すべてがすぐに機能しました。古い URL をより美しいものにマッピングするのは少し面倒でしたが、いくつかのリダイレクトルールを書いた後、すべてが正常に動作しました。料金体系も合理的で、サーバーリソースに対して課金されます。すべての追加サービスはベンダーロックインを避けるため避けたほうが良いですが、ホスティングだけが必要でした。
また、vercel も簡単に検討しましたが、Github アカウントでログインし、「自分の代わりに行動する」権限を要求されたため、サインアップ前に諦めました。
ブログの移行が最も難しかったです。最終的にすべてのコンテンツを手動でコピーしました。これは大規模なブログでは推奨されませんが、私たちのブログは投稿が 15 個しかありませんでした。Gatsby は複数のメカニズムをサポートしていますが、技術的なバックグラウンドがない人でも新しいブログ投稿を作成できるようなシンプルなものを求めていました。Markdown を選び、それに従って Gatsby に Markdown ページを読み込む方法を学びました。実際のメカニズムには画像処理を含めて半日かかりました。素晴らしいブログ投稿テーマと画像にはさらに半日かかりました。
すべてのコンテンツを移行し、テーマを大幅に改造した後、Gitlab CI を使ってデプロイを自動化しました。これにより、プッシュするだけでビルドパイプラインがトリガーされ、Firebase にすべてがデプロイされます。
なぜ Github ではなく Gitlab なのか？歴史的な理由で Github がリードしています。現在では、全開発者とプロジェクトの少なくとも 80％が Github を使用しています。一方で Gitlab は機能を提供します。そのため、過去に Github では何年もの間リアルな機能開発が行われなかったため、Gitlab を選びました。Microsoft が Github を買収してから状況が劇的に変わり、Github Actions は画期的なものですが、Gitlab と競うためには依然として長い道のりがあります。したがって、すべてのプロジェクトを Gitlab にホストしている私たちにとって、このプロジェクトでも Gitlab を使用するのは自然な選択でした。
結論
そしてこれが今の状況です：
- G atsby as CMS
- 商用テーマ
- Markdown によるブログ
- Gitlab CI による自動デプロイ
- Firebase ホスティング
この結果には非常に満足しており、新しいウェブサイトは以前よりもはるかに見栄えが良くなりました！
