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

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

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

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

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

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

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

  • チームの主な開発者はJavaScript開発者です。

  • フロントエンド開発者は、独自のSitecoreインスタンスを持ちません。

  • アプリのニーズは、コンテンツの観点からは比較的単純です。

  • 同社は、後にSitecoreに統合されるJSSアプリを構築するために、外部のフロントエンドエージェンシーを雇っています。

大事な

コードファースト ワークフローの使用を検討する場合は、ワークフローを正しく選択するために、この手法の制限に注意することが重要です。

アプリの初期デプロイ

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

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

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

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

アプリの増分デプロイ

Sitecoreにデプロイする必要がある新しいコンポーネントを追加した場合は、必要に応じて --includeContent --includeDictionaryオプションを指定してjss deploy appコマンドを使用すると、インポート プロセスで必要な変更が実行されます。

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

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

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

これをさらにサポートするために、JSSには、生成されたすべてのテンプレートに自動的に適用されるコンテンツワークフローが含まれています。ワークフローでは、コンテンツ項目の所有権を指定するためのDevelopment Mode状態とContent Mode状態を定義します。

Sitecore content tree for JSS Development Workflow

次の表は、JSS Development Workflowの状態をまとめたものです。

モード

形容

Development Mode

インポート プロセスでは、フィールド値とルート項目レイアウトを上書きできます。

Content Mode

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

メモ

デフォルトでは、Development Modeワークフローの状態は公開できません。JSSサイトのコンテンツ データベースがmaster以外に設定されているため、ワークフローと発行を有効にしても、ワークフローの承認なしにJSSアプリ マニフェストからインポートされたコンテンツ アイテムは発行されません。アプリベースのコンテンツを公開可能と見なす必要があるユースケースでは、Development ModeワークフローアイテムのFinalチェックボックスにチェックを入れます。

Development Modeには、アイテムをContent Modeに移動する __OnSaveコマンドが含まれています。デフォルトでは、アイテムにコンテンツが変更されたと、保存時にアイテムが強制的にContent Modeされ、後続のインポートによる上書きを回避できます。

アイテムをDevelopment Modeに戻すには、Allow Developer Overwriteアクションを使用できます。

大事な

アクションAllow Developer Overwriteの使用は、ルートやそのデータソースに対する単純なコンテンツ変更のシナリオ、またはレンダリングが共有レイアウトに追加された場合に制限することをお勧めします。

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

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

  • コンテンツ テスト。

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

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

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

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

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

  • アプリによって生成されたルート テンプレート。

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

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

  • レンダリング。

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

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

Import process notification about skipping non-writable item

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

Code-first import security presets

プリセット

形容

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開発者をチームに配置してテンプレートの設計に協力することをお勧めします。

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

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