開発者向け
コマンドラインインターフェイス（CLI）を使用した移行の自動化
By Corey Hamilton
新しい環境に変更を展開することは、環境の違いについて質問がある場合、または関連するすべての項目が考慮されているかどうかについて、神経を痛める経験になる可能性があります。幸い、このプロセスを自動化すると、これらの質問の多くが早い段階で削除されるため、環境の信頼性が高まり、開発者の頭痛の種が少なくなります。
このエクスペリエンスを容易にするために、Kontentチームは、コンテンツの更新をさまざまな環境に移行するためのコマンドラインインターフェイス（CLI）フレームワークを作成しました。このフレームワークをお気に入りの継続的インテグレーションツールと組み合わせて、自動展開プロセスの一部として変更を展開できます。これは、コンテンツタイプと関連するコンテンツアイテムをプログラムで更新する機能を追加した、管理APIの最新の改善を活用しています。
開発者から聞いた最も一般的なユースケースの1つは、既存のコンテンツタイプの変更に関係しています。コンテンツタイプを更新してテスト環境にデプロイする必要があるだけでなく、それに関連するコンテンツアイテムも、新しい構造に合わせて更新する必要があることがよくあります。
最近、私たちは独自のkontent.aiWebサイトでこの課題に遭遇しました。最初にWebサイトを構築したときに、各パートナーの情報を表示するコンテンツタイプを作成しました。新しいWebサイトを立ち上げた後、いくつかのパートナーがすべての地域オフィスをプロファイルページにリストすることを望んでいるというフィードバックを受け取り始めましたが、1つの場所を説明するコンテンツタイプしか作成していませんでした。この変更を処理するために、次の手順を実行してコンテンツタイプとパートナーデータを更新し、それらの変更をテスト環境にデプロイして、本番Webサイトで何も破損しないようにしました。
- CLIのドキュメントに従って、CLIを利用するようにテスト環境をセットアップしました。
- 各パートナーアドレスが独自のコンテンツアイテムとして保存されるように、新しいアドレスコンテンツタイプを作成しました。
- 新しいアドレスコンテンツタイプの複数のリンクされたアイテムをサポートするように、パートナーコンテンツタイプを更新しました。
- 次に、Partnerコンテンツタイプを使用するコンテンツアイテムのリストを取得し、元のAddressフィールドからデータを取得して、新しいコンテンツアイテムを作成しました（新しいAddressコンテンツタイプを使用）。
- 同じパートナーコンテンツのリストを使用して、各アイテムを更新し、そのパートナーの適切なアドレスコンテンツアイテムにリンクしました。
- 次に、アプリケーションコードを更新して、新しいリンクされた住所アイテムから住所情報を取得しました。
- 移行スクリプトを実行して、新しいコンテンツタイプ、関連するコンテンツアイテム、およびアプリケーションコードをテスト環境に展開しました。
- すべてが徹底的にテストされたら、パートナーのコンテンツタイプから古いアドレスフィールドを削除しました。
もちろん、ライブプロジェクトに飛び込んで、これを初めて試すことは期待していません。そのため、実際のプロジェクトで使用する前に足を濡らす例を提供するCLI MigrationsBoilerplateも作成しました。
これを試してみたら、Kontentの開発者エクスペリエンスの今後の改善に注目してください。複数の環境への展開を容易にすると同時に、コンテンツ管理へのコードファーストアプローチをさらに前進させるために、いくつかのエキサイティングな新機能に取り組んでいます。最後に、すべての開発ニーズを満たしていることを確認したいので、他に対処が必要なユースケースがある場合はご連絡ください。
