機械翻訳について

構成ライフ・サイクル

Visual Builder Studioを使用して行うアプリケーション拡張を含む、すべての構成と拡張は、テスト環境で行う必要があります。 その後、それを本番環境(日常業務で使用する環境)に移行します。

ビジネス・ニーズのために使用するアプリケーション・インスタンスにこれらの変更を直接加えることはしないでください。 これは、作成された構成が不完全または不安定であったり、未検証だったりすると業務に混乱をきたす可能性があるため、非常に重要です。

ページ・コンポーザやアプリケーション・コンポーザなどの構成ツールを使用してアプリケーションを変更するには、サンドボックスを作成してそこに入る必要があります。 これらのツールで行った変更は、XMLファイルとしてサンドボックスに格納されます。 これらの変更は、サンドボックスを公開する際にメインライン・メタデータとマージされます。

ノート: 1つのサンドボックスでの変更は、他のサンドボックスには反映されません。 また、複数のユーザーが同じサンドボックスで作業する場合は、サンドボックス内での競合を回避するために、規定されたガイドラインに従う必要があります。

Visual Builder Studioを使用してアプリケーションを変更する場合、サンドボックスはオプションです。 基礎となるデータ・モデルを変更する必要がある場合のみ、サンドボックスを使用する必要があります。

フレックスフィールド・サンドボックスはテスト専用であり、公開できません。 かわりに、フレックスフィールドUIを使用して、テスト環境にフレックスフィールドをデプロイできます。 テスト環境にデプロイする前にフレックスフィールド構成をテストするには、フレックスフィールド・サンドボックスにそのフレックスフィールド構成をデプロイする必要があります。 サンドボックスにデプロイする変更は、テスト環境から分離されます。 セッションでフレックスフィールド・サンドボックスをアクティブにしているユーザーのみ、変更を確認できます。 サンドボックスでの変更に問題がないことを確認した後、変更をテスト環境にデプロイできます。

次に、一般的な構成ライフ・サイクルの例をいくつか示します。

構成ツールを使用したアプリケーション構成

  1. アプリケーションをサンドボックスで構成します。

  2. サンドボックスの変更を検証します。

  3. サンドボックスが公開され、テスト環境にデプロイされます。

  4. 品質保証が、すべての構成が完了して公開された後に環境全体を検証します。

  5. 構成がテスト環境から本番環境に移行されます。

前述のリストで説明されている典型的な構成 ライフ・サイクルのワークフローを示すイメージ

Visual Builder Studioを使用したアプリケーション拡張

  1. アプリケーション開発者がVisual Builder Studioを使用してアプリケーション変更を行い、その変更を他のチーム・メンバーと共有します。

    オプションで、アプリケーション開発者はサンドボックスを使用して基礎となるデータ・モデルに変更を加えることができます。その場合、変更内容はアプリケーション拡張の変更のデプロイとともに公開する必要があります。

  2. チーム・メンバーが変更をレビューして承認します。

  3. レビューおよび承認された変更がメインラインのリポジトリとマージされます。

  4. アプリケーション拡張の変更がマージされると、ビルドがトリガーされ、変更がテスト環境に自動的にデプロイされます。

  5. 品質保証により、すべての拡張機能がテスト環境にデプロイされた後に、環境全体が検証されます。

  6. 変更がテスト環境から本番環境に移行されます。

前述のリストで説明されている、Visual Builder Studioを 使用したアプリケーション拡張の構成 ライフ・サイクルのワークフローを示すイメージ。