Blog

モノリシックシステムの時代には、最初に適切なシステムを選択することが重要でした。その決定は必然的に何年もの間単一のベンダーにあなたを閉じ込めました。今日、マイクロサービスの時代では、ベンダーはシステムを簡単に切り替えることができると主張しています。ヘッドレスCMSを切り替えるときに「簡単」とはどういう意味か、そしてその決定があなたの仕事に費用をかける可能性があるかどうかを見てみましょう。

この記事では、最初に、移行の実際の意味と、実行する必要のある一般的な手順について説明します。第2部では、実際のContentfulプロジェクトをKentico Kontentに移行し、注意が必要な部分を指摘します。

移行

数年前、私の友人から、彼女のWebサイト（彼女はフードデリバリーサービスを所有しています）をPrestashopに移行できるかどうか尋ねられました。このウェブサイトは、当時存在しなくなった代理店によって構築されたカスタムCMSの上に構築されました。そこで、ウェブサイトのバックアップをダウンロードして、作業を開始しました。

すべての移行、または少なくともWeb中心の移行では、データとフロントエンドの移行という2つのことを検討しています。

データ移行

まずは商品データです。彼女のeショップには、約500のサンドイッチ、サラダ、デザート、その他のアイテムがありました。すべてのアイテムには、一連の写真、栄養表、説明、タグなどが含まれていました。ご想像のとおり、それらを新しいソリューションに手動でコピーして貼り付けるには1週間かかります。そこで、移行スクリプトを作成しました。次に、カテゴリ用にもう1つ。そしてもう1つはコンテンツページ用です。そしてもう1つ...あなたはアイデアを得る。それでも実行可能です。必要なデータを選択して、新しいデータ構造にマッピングします。

移行の最悪の部分は、非構造化データです。私の場合、それらはコンテンツページでした。すべてのコンテンツの50％以上がコンポーネント、ウィジェットに保存され、テンプレートにハードコードされているなど、プログラムでデータを抽出することはほとんど不可能です。すべてのエッジケースを処理する移行スクリプトの実装は、手動のコピー貼り付けよりも時間がかかる可能性があります。

フロントエンドの移行

移行の2番目の部分は、フロントエンドでした。同じフロントエンドアセットを使用でき、ルックアンドフィールの最適化に何日も費やさないため、そこでは簡単になります。移行の一環として外観を更新する場合を除きます。それでも、すべてのコードブロックを見つけて、XSLTからSmartyに変換する必要がありました。これは、Prestashopがテンプレートに使用するものだからです。

マイクロサービスの時代

あるモノリスから別のモノリスへの移行を処理するのは難しいことがわかります。意味のある移行作業と手動でコピーする作業の間に線を引く必要がありました。結局、とにかく5週間以上の作業が必要でした。

今日、私たちはマイクロサービスアーキテクチャを使用する傾向があります。これは、すべての移行の1つの重要な側面を変更します。コンテンツ構造。

編集者がページに対して持つ可能性のあるすべてのユースケースをカバーできるようにするために、モノリスはユーザーと開発者が任意の構造の外部にデータを保存できるようにしました。コンポーネントはキーと値のペアを格納する必要がありましたか？それともほんの少しのHTML？問題ない。

マイクロサービススペースのコンテンツストレージを表すヘッドレスCMSは、「非構造化データ」の問題を解決しました。彼らがしなければなりませんでした。モノリスはWeb中心でしたが、ヘッドレスCMSはコンテンツを複数のチャネルに配信します。そのため、どこにでも何も保存することはできませんが、常にコンテンツを構造化するように導きます。たとえば、スマートウォッチアプリはとにかくリッチHTMLコードで何をしますか？

また、実装から切り離すことにより、フロントエンドの移行を簡素化しました。実際には、実装でさまざまなデータスキームを解決する必要がありますが、このプロセスを容易にするSourcebitなどのデータ正規化ツールはすでに見られます。興味がある場合は、 Sourcebitの詳細をご覧ください。

ヘッドレスCMS間のコンテンツ移行

しかし、本物を見てみましょう。私は7件のブログ記事と私からの私についてのページのコンテンツを格納するためにContentfulを使用し、個人サイトを。

ブログの投稿には画像、URLスラッグ、リッチテキストが必要であるのに対し、 About m eページにはネストされたアイテムが含まれているため（以下に概説）、実際にはCMSの機能のかなりの部分をカバーしています。

Sourcebitを介してNext.jsWebサイトに接続されているものすべて。すべてを別のヘッドレスCMSであるKenticoKontentに移行したいと思います。

純粋なAPI移行

最初のオプションは、これらのヘッドレスCMSの管理APIを使用して、移行スクリプトを作成することです。これは、友達のWebサイトで行ったことと少し似ています。データを調整して別のMySQLデータベースに保存するために、いくつかのSQLクエリを作成しました。管理APIを使用すると、はるかに簡単になります。移行スクリプトの実装に使用しているプラットフォームのすべてのツールにアクセスできます。多くの場合、CMSは通信を処理するSDKも提供するため、実際のデータ移行に集中できます。

私の場合、ContentfulとKontentの両方が、JavaScriptと.NET用のコンテンツ管理SDKを備えています。これらは、私が最近最もよく使用するプラットフォームです。

移行ツール

しかし、確かにあなたは、あるCMSから別のCMSにコンテンツを移動しようとする最初の人ではありません。私がWindowsからAppleTVにビデオをストリーミングしようとした最初の人ではなかったのと同じように、この場合を除いて、最初の問題には実際に解決策があります。オープンソースは最近非常に人気があり、多くの開発者が実装をコミュニティで利用できるようにしているので、ソースとターゲットのCMS間で移行するためのツールがあるかどうかを常に確認しています。

ContentfulからKontentへの移行には、MatthewCastrillon-Madrigalによって開発されたオープンソースツールがあります。彼はこれを使用して、これら2つのCMS間で大規模で複雑なプロジェクトを移行したため、実際には実験的なツールではありません。実装には、Contentfulからコンテンツモデルとコンテンツアイテムをダウンロードしてローカルに保存し、Kontentに対してそれぞれのAPI呼び出しを実行して、同じ構造とデータを作成する一連のシェルスクリプトが含まれています。

つまり、移行のために作成する必要があるのと同じコードです。

構成

それがどのように機能するかを見てみましょう。まず、両方のCMSへの接続を設定する必要があります。

yarn program --contentful_setup

yarn program --kontent_setup

このツールは、プロジェクトIDとAPIキーを要求し、それらをローカル構成ファイル.environments.jsonとexport /config.jsonに保存します。

アクション

次に、Contentfulからデータのフェッチを開始できます。

注：you'reは、Windows上で動作している場合は、you'll必要が使用するのgitのbashの移行を実行するためにクライアントを。ここで説明するように、 。 / src /index.tsでシェルの実行を微調整する必要がある場合もあります。

yarn program --fetch

これにより、コンテンツモデル、コンテンツアイテム、およびアセットがローカルフォルダー構造にダウンロードされます。

次に、データはKontent構造にマップされ、次の方法でKontentに送られます。

yarn program --migrate

このコマンドを実行すると、移行ツールはデータのCMSへのアップロードを開始します。画面に進行状況が表示され、失敗した操作がログに記録されます。

私は解決しなければならない2つの問題に出くわしました：

• 言語
  Kontentへのデータのアップロードを開始する前に、Kontentのデフォルト言語のコードネームをContentfulで使用していたコードネームに変更してください。私はen-USを使用していました。 Kontentでデフォルト言語のデフォルトの「デフォルト」コードネームをそのままにしておくと、1つの余分な言語になってしまいます。
• プロジェクトのクリア
  物事はうまくいかない。特にウェブサイトの開発で。コードがすぐに機能する場合、コードを信頼しない傾向があります:-)。インポートが失敗した場合、またはツールを誤って構成した場合は、それを繰り返すことができます。プロジェクトがクリーンで、次のインポートの準備ができていることを確認するには、 Kontent TemplateManagerのクリーナーを使用します。 Contentfulからデータを再フェッチする必要がある場合もあります。

私はこれらのブログ投稿に行き着きました：

そして、これらのネストされたアイテムは、 Aboutmeページのコンテンツアイテム内に正しく配置されています。

インポートでは、すべてのアセットも正しく処理されました。フロントエンドを調整する方法を見てみましょう。

フロントエンドでのヘッドレスCMSの切り替え

私のウェブサイトはNext.jsとSourcebitを使用して構築されており、データプロバイダー間の切り替えに必要な労力を最小限に抑えることができます。 Sourcebitの動作に慣れていない場合は、 この記事を参照するか、このビデオをご覧ください。データを空のKontentプロジェクトにインポートしたことを考えると、テンプレートやコンポーネントのコードを掘り下げるよりも、構成を簡単に変更できると期待していました。

これは、Contentfulに接続したときのWebサイトの外観です。

Sourcebitを再初期化し、プロジェクトルートで次のコマンドを実行して新しいCMSを選択することにより、データソースを変更できます。

npm init sourcebit

新しいプロジェクトIDと言語コードネームを追加するように求められます。私の場合、コードネームen-USが新しく変更された言語は1つだけです。ウィザードの他のすべての手順は、古いCMSの場合とまったく同じです。

必要な変更

スイッチの直後にプロジェクトを実行すると、修正が必要ないくつかのエラーが表示されます。

• 画像
  ブログの投稿がレンダリングされていないようです。ただし、問題は画像が欠落していることです。ブログ投稿のコンテンツアイテムに画像が含まれている場合、 post.page.image使用すると、そのURLはpost.page.image.urlではなくpost.page.image.url下に表示されます。
  ブログ投稿でリモート画像を使用している場合、フィールドのコードネームはpost.page.image_urlではなくpost.page.imageUrlます。
• リッチテキスト解決
  すべてのCMSは、リッチテキストの解決をわずかに異なる方法で処理します。したがって、Contentfulからのデータ用に実装されたリゾルバーは廃止されており、Kontent用に新しいリゾルバーを追加する必要があります。

これらの小さな違いは、私がしなければならなかった唯一の変更でした。これで、Webサイトが正常に移行され、別のCMSからのデータが使用されます。

ただの実験？

それで、あなたはそのプロセスが簡単だと思いますか？

私の場合、コンテンツの移行にはアクセス構成のみが必要でした。機能セットが異なるため、異なるCMS間でデータを1：1に変換できるとは限らないため、スクリプトを調整する必要がある場合があります。そして、それは実装がオープンソースであるために可能です。

フロントエンドの移行は、主にSourcebitによって行われたデータの正規化のおかげで、いくつかの小さな調整の後に機能しました。

ご存知のように、最近では、移行は過度に恐れるものではありません。次のプロジェクトで使用するツールを決定する前に、適切な調査を行う必要があります。しかし、マイクロサービスのツールは驚くほど急速に進化しているため、間違いを犯したり、後でより良いツールを見つけたりしても、仕事に費用がかかることはありません。

私のGitHubで実装がどのように見えるかを自分で見てください。