---
title: "コードファーストの開発ワークフロー"
slug: "code-first-development-workflow"
abstract: "コードファースト開発、アイテム所有権、JSSアプリのデプロイの概要"
---
# コードファーストの開発ワークフロー

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

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

以下の場合、コードファーストのワークフローを選ぶことをお勧めします:

-   あなたは設計の初期プロトタイピング段階にあり、Sitecoreインスタンスがまだ利用可能ではないかもしれません。
-   チームの主な開発者はJavaScript開発者です。
-   フロントエンド開発者は自分専用のSitecoreインスタンスを持っていません。
-   アプリのコンテンツ的ニーズは比較的シンプルです。
-   同社は外部のフロントエンド代理店を雇い、後にSitecoreに統合されるJSSアプリの開発を依頼しています。

> !重要コードファーストワークフローの利用を検討する際は、この手法の限界を理解し、正しいワークフロー選択を確実にすることが重要です。

## 初期アプリの展開

コード優先のJSSアプリケーションがSitecoreに展開できる準備ができたら、[JSSアプリを接続し、Sitecoreに展開](https://doc.sitecore.com/xp/ja/developers/hd/19/sitecore-headless-development/walkthrough--connecting-a-jss-application-to-sitecore.html "Walkthrough: Connecting a JSS application to Sitecore")してください。

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

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

初期のアプリ展開後は、まずコード先行開発を続けるか、[Sitecore先行に切り替え](https://doc.sitecore.com/xp/ja/developers/hd/19/sitecore-headless-development/transitioning-from-code-first-to-sitecore-first.html "Transitioning from code-first to Sitecore-first")ることができます。

## インクリメンタルアプリの展開

Sitecoreにデプロイしなければならない新しいコンポーネントを追加した場合、コマンドjss deploy appを使い、必要に応じてオプション \--includeContent --includeDictionary設定し、[インポートプロセス](https://doc.sitecore.com/xp/ja/developers/hd/19/sitecore-headless-development/characteristics-of-the-jss-code-first-import-process.html "Characteristics of the JSS code-first import process") が必要な変更を行います。

コンテンツユーザーの活動が始まると、開発者は通常、*/sitecore/Layouts*や */sitecore/Templates*などSitecoreコンテンツツリーの一部を所有し、コンテンツオーサーは */sitecore/Content*の項目を所有しています。したがって、コンテンツオーサーがすでに活動を開始している場合は、コードアーティファクトのみをデプロイし、コマンドjss deploy filesを使います。このコマンドはルート、コンテンツ、画像などのアイテムを展開しません。

## コンテンツワークフローと開発者のオーバーライト

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

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

![Sitecore content tree for JSS Development Workflow](https://doc.sitecore.com/api/markdown-image/xp/ja/developers/hd/19/sitecore-headless-development/images/jss-workflow.png)

以下の表は*JSS Development Workflow*の状態をまとめたものです:

モード

概要

*Development Mode*

インポートプロセスはフィールド値の上書きやアイテムレイアウトのルーティングが可能です。

*Content Mode*

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

> !注デフォルトでは、*Development Mode*ワークフローの状態は公開できません。コンテンツデータベースがmaster以外の設定に設定されているJSSサイトは、ワークフローと公開を有効にしている場合、ワークフロー承認なしにJSSアプリマニフェストからインポートされたコンテンツアイテムは公開されません。アプリベースのコンテンツが公開可能とみなされるユースケースについては、*Development Mode*ワークフロー項目の最終チェックボックスにチェックを入れてください。

*Development Mode*アイテムを*Content Mode*に移動させる*\_\_OnSave*コマンドが含まれています。デフォルトでは、アイテムへの内容変更は保存時に強制的に*Content Mode*に切り替えられ、その後のインポートによる上書きを防ぎます。

アイテムを元の*Development Mode*に戻すには*Allow Developer Overwrite*アクションを使えます。

> !重要アクション*Allow Developer Overwrite*の使用は、ルートやデータソースへの単純なコンテンツ変更、または共有レイアウトにレンダリングが追加された場合にのみ限定することを推奨します。
> 
> アクション*Allow Developer Overwrite*を使うのは危険です。開発者が最新のコンテンツを引っ張らないと、次にインポートされるものが既存のアイテムコンテンツを上書きしてしまいます。たとえ開発者がローカルデータを更新するためにプルオールルートデータを使っていても、データや設定が失われる可能性は依然としてあります。これはルートデータがアイテムの完全なシリアライズではないためです。失われる可能性のあるデータには以下のようなものがあります:
> 
> -   パーソナライズルール/条件付きレンダリング。
>     
> -   内容テスト。
>     
> -   最終レイアウト(ルートデータに取り込まれますが、共有レイアウトとして再インポートされます)。
>     
> -   特定のデータソースの場所(インポートはアプリに設定されたデータソース戦略を利用します)。
>     

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

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

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

-   アプリが生成したルートテンプレート。
-   データソースのテンプレートとそのフィールド。
-   アプリが生成するメインレイアウトです。
-   レンダリング。
-   プレースホルダー設定。

item:writeやitem:createの権限や特定のインポートユーザー *sitecore\\JSS Import Service Users*へのアクセスを拒否することで、Sitecore開発者や管理者はフロントエンド開発者が作成・更新できる項目を制限できます。インポートプロセスはそれらの項目をスキップし、スキップしたことを示す警告を出力します。これにより、Sitecore開発者は上書きされる心配なくインポート済みの項目を変更できます。

![Import process notification about skipping non-writable item](https://doc.sitecore.com/api/markdown-image/xp/ja/developers/hd/19/sitecore-headless-development/images/code-first-security-item-skip.png)

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

![Code-first import security presets](https://doc.sitecore.com/api/markdown-image/xp/ja/developers/hd/19/sitecore-headless-development/images/code-first-security-presets.png)

プリセット

概要

*No overwrite*

アイテム:writeへのアクセスを *sitecore/JSS Import Service User* 役割に対して拒否します。インポートがアイテムのフィールド値を上書きしてはならないことを示します。

*新しい子供はなし*

アイテム:作成で *sitecore\\JSS Import Service User* 役割に対してアイテムおよびその子孫へのアクセスを拒否します。インポートがアイテムの下で新しい子を作成してはいけないことを示します。

この仕組みを使うには、フロントエンド開発者とSitecore開発者の間で追加の調整が必要であり、これらのセキュリティプリセットで保護されたアイテムは変更が必要です。

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

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

アプリケーション構造が不安定な初期開発時には、各インポートを新たに始めることが有効です。フルワイプモードでインポートすると、インポートプロセス開始時に現在設定されたパスでインポート済みアイテムが削除されます。主にローカル開発や継続的統合(CI)構成を目的としており、フロントエンド開発者からのチェックインがCI環境に自動的にデプロイ/インポートされます。

フルワイプインポートにはダブルロックがあり、2か所で有効化する必要があります:

-   Sitecore設定の SitecoreJSS.WipeAllowed 設定は、設定パッチで有効にする必要があります(true)。 SitecoreJSS.WipeMode 設定はインポートがリサイクル(デフォルト)するか、アイテムを強制的に削除するかを制御するために使えます。この設定の変更は自己責任で行ってください。
-   JSS CLIコマンドには \--wipe パラメータ(エイリアス \-w)が含まれなければなりません。例えば、 jss deploy app -c -d -w.

> !重要コンテンツエントリや本番環境では、完全ワイプモードを有効にしてはなりません。Sitecore設定ルールはデフォルトで存在しており、スタンドアロンロールでのSitecoreインストール時にはWipeAllowedグローバル設定がデフォルトでtrueとなり、開発中の消去が容易であり、Content Managementロールの本番サイトを誤って消去するのを防ぎます。さらにセキュリティを高めるために、JSSインポートロールやユーザーのインポートツリーの関連部分へのitem:deleteアクセスを無効にすることも可能です。

## 長期的なコードファースト開発におけるリスクの低減

時には、開発期間の大部分をまずコードから開発することが求められることもあります。

このような状況でリスクを減らすために:

-   フロントエンド開発者のオンボーディングの一環として、フロントエンド開発者にSitecoreエディターを試す機会を与えることを推奨します。著者の視点から見ると、コンポーネント、フィールド、レンダリングパラメータ、プレースホルダーを理解することが重要であり、Sitecore編集インターフェースでコンポーネントを特別な方法でレンダリングする必要がある場合もあります。例えば、モーダルは通常ページ読み込み時に非表示ですが、Experience Editorでページ読み込み時に見えるため、コンテンツオーターがモーダルコンテンツを編集できます。
-   すべてのフロントエンド開発者が切断/コード優先モードで働く必要がある場合は、テンプレート設計に協力するためにSitecoreの開発者をチームに加えることをおすすめします。