コード ファーストの開発ワークフロー

Version: 20.x
日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

コード ファーストのワークフローでは、JSS アプリは一連のファイルからコンテンツ データとデータ スキーマのマニフェストを作成します。これにより、Sitecore インスタンスなしで、ローカルのモック コンテンツを使用して JSS アプリを実行できます。

このモードでは、JSS アプリがすべてのアーティファクトのマスター コピーになります。マニフェストは Sitecore にインポートされ、アプリをサポートするために必要な構造を作成します。

次の場合は、コード ファースト ワークフローを選択することをお勧めします。

  • 設計の初期のプロトタイプ段階にあり、Sitecore インスタンスがまだ利用できない場合。

  • チームの主な開発者が JavaScript 開発者である場合。

  • フロントエンド開発者は独自の Sitecore インスタンスを持っていない場合。

  • アプリのニーズが、コンテンツの観点から見て比較的単純な場合。

  • 外部のフロントエンド エージェンシーに JSS アプリのビルドを依頼し、あとで Sitecore に統合する予定の場合。

重要

コード ファースト ワークフローの使用を検討する場合は、この手法の制限を認識して、ワークフローを正しく選択できるようにすることが重要です。

アプリの初期デプロイメント

コード ファーストの JSS アプリケーションを Sitecore にデプロイする準備ができたら、JSS アプリを Sitecore に接続してデプロイします。

アプリは、初期コンテンツのすべての階層を駆動します。JSS アプリのすべてのルートがページ レベルのアイテムになり、各コンポーネントがレンダリング アイテムになります。JSS アプリは、ページ レベルのアイテムの表示の詳細も決定します。

プロセスの最後までに、必要なものがすべて Sitecore で自動的に作成されます。アプリは非接続モードと同じようにレンダリングされることが期待されます。

最初のアプリのデプロイ後は、引き続きコード ファーストで開発することも、Sitecore ファーストに切り替えることもできます。

アプリの増分デプロイメント

Sitecore にデプロイする必要がある新しいコンポーネントを追加した場合は、該当する限り、jss deploy app コマンドを --includeContent --includeDictionary オプションで使用できます。インポート プロセスが必要な変更を行います。

コンテンツのユーザー アクティビティが開始すると、開発者は通常、Sitecore のコンテンツ ツリーの一部 (例: /sitecore/Layouts/sitecore/Templates)、およびコンテンツ作成者が所有する /sitecore/Content 配下のアイテムを所有します。したがって、コンテンツ作成者が既にアクティビティを開始している場合は、どのアイテム (ルート、コンテンツ、画像) もデプロイしない jss deploy files コマンドを使用して、コード アーティファクトのみをデプロイすることをお勧めします。

コンテンツ ワークフローと開発者の上書き

JSS インポート プロセスは、設定されたインポート ユーザーが書き込み権限を持っていないアイテムをスキップするように設計されています。これにより、Sitecore セキュリティを使用して、開発者が所有していないコンテンツがインポート プロセスによって上書きされないようにすることができます。

この機能をさらにサポートするため、JSS には、生成されたすべてのテンプレートに自動的に適用されるコンテンツ ワークフローが含まれています。このワークフローは、開発モードおよびコンテンツ モードの状態を定義することで、コンテンツ アイテムの所有権を指定します。

JSS 開発ワークフローの Sitecore コンテンツ ツリー

次の表に、JSS 開発ワークフローの状態をまとめました。

モード

説明

開発モード

インポート プロセスは、フィールド値やルート アイテム レイアウトを上書きする場合があります。

コンテンツ モード

インポート ユーザーは、アイテムの書き込みアクセスを拒否されます。インポート プロセスは、アイテムへの書き込みをスキップします。ルート アイテムの場合は、データソース アイテムに対するレンダリングの変更や更新もスキップされます。

注記

既定では、開発モードのワークフローの状態はパブリッシュができません。master 以外に設定され、ワークフローとパブリッシュを有効にするコンテンツ データベースを持つ JSS サイトは、JSS アプリのマニフェストからインポートされたコンテンツ アイテムを、ワークフローの許可なしにパブリッシュすることはありません。アプリ ベースのコンテンツをパブリッシュ可能であるとみなすユース ケースでは、開発モードのワークフロー アイテムで [最終] チェックボックスをオンにします。

開発モードには、アイテムをコンテンツ モードに移動する __OnSave コマンドが含まれています。既定では、アイテムへのコンテンツ変更はすべて、後続のインポートによる上書きを回避するため、保存時にそのアイテムをコンテンツ モードに移動します。

アイテムを開発モードに戻すには、開発者による上書きを許可するアクションを使用します。

重要

開発者による上書きを許可するアクションの使用は、ルートやデータソースへのシンプルなコンテンツ変更や、レンダリングが共有レイアウトに追加された場合などに制限することをお勧めします。

開発者による上書きを許可するアクションの使用は危険です。開発者が、最新のコンテンツをプルしなかった場合、次にインポートしたコンテンツにより、既存のアイテム コンテンツが上書きされてしまうためです。開発者が pull-all-route-data を使用してローカル データを更新しても、データや設定が失われる場合があります。これは、ルート データがアイテムの完全なシリアライゼーションではないためです。失われる可能性のあるデータは次のとおりです。

  • パーソナライゼーション ルール / 条件付きレンダリング。

  • コンテンツ テスト。

  • 最終レイアウト (ルート データにプルされますが、共有レイアウトとして再インポートされます)。

  • 特定のデータソースの場所 (インポートは、アプリに設定されているデータソース戦略を利用します)。

インポート プロセスを使用する場合は、アイテムの所有権を考慮することを強くお勧めします。インポート プロセスを通じてルートを更新するのではなく、コンテンツ作成者がルートで利用できる新しいコンポーネントのみを提供します。

フロントエンド開発者と Sitecore 開発者のアイテムの所有権

JSS は Sitecore セキュリティを使用して、インポート時に上書きしてはならない開発者アイテムを指定します。これらは通常、次のような項目が含まれます。

  • アプリの生成されたルート テンプレート。

  • データソース テンプレートとそのフィールド。

  • アプリの生成されたメイン レイアウト。

  • レンダリング。

  • プレースホルダーの設定。

sitecore\JSS Import Service Users ロール、または特定のインポート ユーザーに対して item:write および item:create のアクセスを拒否すると、フロントエンドの開発者が作成、更新できるアイテムを Sitecore の開発者や管理者が制限できます。インポート プロセスはそれらのアイテムをスキップし、そのことを知らせる警告を出力します。これにより、Sitecore の開発者はインポートしたアイテムを変更しても、変更が上書きされてしまう心配はありません。

書き込み不可のアイテムのスキップに関するインポート プロセスの通知

これらの制限を容易にするために、JSS はインポート プロセスからアイテムをすばやく保護するために使用できる 2 つのセキュリティ プリセットを提供しています。

コード ファースト インポート セキュリティ プリセット

プリセット

説明

No overwrite

sitecore/JSS Import Service User ロールに対して、アイテムとその子孫への item:write アクセスを拒否します。つまり、インポートはアイテムのどのフィールド値も上書きしません。

No new children

sitecore\JSS Import Service User ロールに対して、アイテムとその子孫への item:create アクセスを拒否します。つまり、インポートはアイテムの配下に新しい子を作成しません。

このメカニズムを使用するには、これらのセキュリティ プリセットで保護されているフロントエンド開発者と Sitecore 開発者のアイテムを変更する必要がある場合に、追加の調整が必要になります。

JSS が触れないフィールドを更新する場合は、書き込みを制限する必要はありません。JSS インポートは、フル ワイプ モードで実行しない限り、アイテムを削除しません。ただし、これらの制限を回避すると、アイテムの所有権が混乱し、JSS インポートが将来これらのフィールドのサポートを追加する場合に問題が発生する可能性があります。

フル ワイプ モードでのインポート

アプリケーションの構造が変化しやすい初期開発中に、インポートするごとに新しく始めると便利な場合があります。フル ワイプ モードでインポートすると、インポート プロセスの開始時に設定されていたパス上にインポートされたアイテムがすべて削除されます。これは主に、フロントエンド開発者からのチェックインが継続的インテグレーション (CI) 環境に自動的にデプロイ/インポートされる CI 設定またはローカル開発を対象としています。

フル ワイプ インポートには二重ロックがあり、次の 2 つの場所で有効にする必要があります。

  • Sitecore の SitecoreJSS.WipeAllowed の設定を設定パッチで有効 (true) にする必要があります。SitecoreJSS.WipeMode の設定は、アイテムをインポート リサイクル (既定) するか、アイテムをハード削除するかを制御するために使用できます。この設定は、自己責任で変更してください。

  • JSS CLI コマンドには --wipe パラメータ (エイリアス: -w) を含める必要があります。たとえば、jss deploy app -c -d -w とします。

重要

コンテンツ エントリまたは本番環境では、フル ワイプ モードを有効にしないでください。Sitecore の設定ルールは既定で決められているため、WipeAllowed グローバル設定は、スタンドアロン ロールでの Sitecore インストールに対しては既定で true となり、開発中に簡単にワイプできるようにすると同時に、Content Management ロールで本番サイトを誤ってワイプするのを防止します。セキュリティを強化するため、JSS インポート ロールまたはユーザーのコンテンツ ツリーの関連部分への item:delete アクセスを無効にすることもできます。

ログ ターム コード ファースト開発におけるリスクの軽減

チームは、開発時間のほとんどをコード ファーストで開発することが求められる場合があります。

このようなシナリオでリスクを軽減するには:

  • フロントエンド開発者のオンボーディングの一環として、フロントエンド開発者に Sitecore エディターを試す機会を与えることをお勧めします。作成者の観点から、コンポーネント、フィールド、レンダリング パラメーター、およびプレースホルダーがどのようなものであるかを理解することが重要です。また、Sitecore の編集インターフェイスでは、コンポーネントを特殊な方法でレンダリングする必要がある場合もあります。たとえば、モーダルは通常、ページの読み込み時には非表示になりますが、エクスペリエンス エディターではコンテンツ作成者がモーダル コンテンツを編集できるように、ページの読み込み時に表示されます。

  • すべてのフロントエンド開発者が非接続/コード ファースト モードで作業する必要がある場合は、チームの Sitecore 開発者が連携してテンプレートの設計を行うことをお勧めします。

何かフィードバックはありますか?

この記事を改善するための提案がある場合は、