Document

Kentico Kontentの環境では、開発者は本番プロジェクトのスナップショットを作成できます。環境内では、本番環境に影響を与えることなく、既存のコンテンツモデルとコンテンツ自体に安全に変更を加えることができます。非本番環境内のコンテンツとアセットは、サブスクリプションプランの制限にはカウントされません。

目次

• なぜ環境を使用するのですか？

• 環境との継続的インテグレーション

• 環境を管理する

• 環境間の変更の移行

なぜ環境を使用するのですか？

環境とは、物事を隔離して安全にテストするための手段です。本番環境で何かを変更する必要に迫られたことはありませんか？誤字脱字の修正や型の制限の追加などの小さなものであれば、多くの場合、壊れることのない変更です。そのため、プロジェクトに接続されているアプリには影響を与えません。しかし、本番環境で破壊的な変更を行う必要がある場合（例えば、要素のタイプを変更したり、既存のコンテンツモデルを調整したり、プログラムで何百ものアイテムに構造を追加したりする場合）は、別のサンドボックス環境を使用して準備することをお勧めします。

環境との継続的インテグレーション

環境を使えば、Kontentプロジェクトを簡単に反復し、アプリを継続的に改善することができます。例えば、プロジェクトでの画像の使用方法を変更し、コンテンツ・コンポーネント内のアセットに移行したいとします。このような場合には、まず本番プロジェクトのスナップショットとなる環境を作成します。これにより、本番データを維持したまま開発することができます。

その環境をローカルで動作しているアプリに接続し、アプリと環境の両方に変更を加えていきます。そして、アプリがその変更をどのように処理するかを検証します。すべてが正常に動作したら、新しい環境から本番環境への移行を準備します。最初に別の環境に対してマイグレーションを実行し、希望通りになることを確認します。

完了して本番環境が更新されたら、環境を削除します。WebhooksやManagement APIに依存する統合を開発する際にも、このアプローチを使用できます。各環境は独自のAPIキーのセットを持ち、独自のWebhookを発行することができます。

環境を管理する

すべてのKontentプロジェクトには、Productionと呼ばれるデフォルトのマスター環境が付属しています。この環境は削除も名前の変更もできません。お客様のサブスクリプションプランが許す限り、いくつでも環境を作成することができます。環境間で変更を同期する必要がある場合は、コードファーストの移行をお勧めします。

環境とその使い方

環境は開発用のツールであり、コンテンツ制作用ではありません。つまり、Manage environments権限を持つユーザーのみが、環境を使用および管理することができます。コンテンツの制作やプレビューには、本番環境を使用してください。

コンテンツアイテムとアセットに対するサブスクリプションプランの制限は、本番環境に対してのみカウントされます。帯域幅とAPIコールはすべての環境でカウントされます。

環境の作成

環境を作成するときは、常に Production などの既存の環境をベースにします。新しい環境は、ソース環境のコピーになります。すべてのアイテム、アセット、タイプ、スニペット、タクソノミー、コレクション、ロール、ワークフロー、および言語は、新しい環境にも含まれます。WebhookやプレビューURLは新しい環境にはありません。

新しい環境を作成するには、Project settings→Environmentsと進み、Create new environmentをクリックします。環境を表示しているときに、More actions→Cloneを選択して、環境をクローンすることもできます。

環境の切り替え

複数の環境を持つプロジェクトでは、選択したプロジェクトの環境を素早く切り替えることができるドロップダウンリストが表示されます。

環境間の変更の移行

ある環境で行われた変更は、すぐには他の環境に同期されません。ある環境から別の環境へ変更を移行するには、移行スクリプトを書く必要があります。このコードファーストのアプローチは、データベースのコピーを作成し、オリジナルに対してスクリプトを実行する前に、コピーに対してスクリプトを実行するという、データベースの移行の取り扱いに似ています。

Kontent環境では、Kontent CLIツールを使用して、特定の環境に対して一連の移行スクリプトを実行することをお勧めします。

移行の例

あなたのプロジェクトに記事があると想像してください。各記事には、テキスト要素に「Jane Doe」として入力された著者がいます。この情報を拡張して、著者の写真と短い経歴を含めることができるようにしたいとします。これらの詳細を各記事に1つずつ追加するのは面倒なので、Authorという新しいコンテンツタイプを作成し、記事から著者を参照するようにします。

その方法のひとつをご紹介します。

1. アプリのコード用に新しい環境と新しいブランチを作成します。

2. 新しい環境にデータを追加するための移行スクリプトを作成して実行します。

   1. Authorコンテンツタイプを作成します。

   2. 記事コンテンツタイプにリンクされたアイテム要素を追加し、著者を参照できるようにします。

   3. 既存のデータを移行します。各著者に対してコンテンツアイテムを作成し、その名前だけを提供します。

3. 新しいデータモデルに対してアプリのコードをテストします。

   この時点では、アプリにはまだ下位互換性があります。

4. 移行スクリプトを実行して、本番環境にデータを追加します。

   移行が完了したら、コンテンツ制作者は、各Authorアイテムの名前、経歴、写真を入力します。

5. アプリケーションの新バージョンをデプロイします。

6. 不要になったオリジナルのAuthorテキスト要素を削除するマイグレーションを作成し、実行します。

   1. コンテンツ削除スクリプトがテスト環境で正しく動作することを確認します。

   2. 本番環境に対して実行します。

Kontent Migrations Boilerplateをご覧になることをお勧めします。ボイラープレートには、独自の移行スクリプトを作成するために使用できるサンプルの移行スクリプトが含まれています。

次のステップ

プロジェクトのクローンを作成するべきか、環境を作成するべきか？

プロジェクトのクローンと環境は同じように機能しますが、その目的は異なります。

• 環境は、安全な場所で本番プロジェクトの変更を準備するために使用します。開発者はその変更を本番プロジェクトに反映させる作業を行います。

• プロジェクトクローニングは、コンテンツ制作のための新しいスタンドアロンプロジェクトを作成するために使用します。例えば、似たようなコンテンツモデルをベースにして、コンテンツが少しだけ異なるプロジェクトを実行したい場合などです。

原文：https://docs.kontent.ai/tutorials/manage-kontent/projects/manage-environments