アップグレードアプローチの選択
概要
Drupal 8へのアップグレードの準備をする際、アップグレードアプローチの計画に時間を費やす価値があります。以前のDrupalサイトのコンテンツは問題なく移行できる可能性が高いですが、Drupal 8サイトの設定には手動のタスクがいくつか必要になる可能性が高いです。たとえば、Viewsモジュールにはまだコアに自動アップグレードがないため、Drupal 8サイトでビューを手動で作成する必要があります。最も適切なアプローチをサイトごとに検討する必要があります。
手動アップグレード後ステップによるシンプルなアプローチ
このアプローチでは、アップグレードは1回実行され、手動アップグレードステップ（例：viewsの作成）は、公開前にDrupal 8サイトで実行されます。
まずアップグレードを練習し、手動アップグレード後に実行されるステップを注意深く記録することをお勧めします。テスト環境に満足したら、同じ手順を繰り返して、クリーンなDrupal 8インストール用のDrupal 8本番環境を構築します。
このアプローチは次に適用できます
手動アップグレードステップ後の増分アップグレード
手動アップグレード後ステップの数と複雑さによっては、Drupal 8サイトで手動アップグレード後ステップを実行している間、古いサイトをオフラインに保てない場合があります。新しいDrupal 8サイトで手動アップグレード後ステップが実行されている間に古いサイトがオンラインの場合、ユーザーが古いサイトでコンテンツを作成または更新している可能性があります。
Drupal 8は追加のアップグレードをサポートしています。これは、新しいコンテンツと更新されたコンテンツを移行するために移行が再度実行されることを意味します。初期アップグレードと増分移行の間に古いソースサイトの設定を変更することはお勧めできません。
このアプローチは次に適用できます
STAGINGおよびPROD環境へのコンテンツのみの移行
Drupal 8の最も強力な新しい概念の1つは、Drupal設定全体をある環境から別の環境にデプロイするために使用できる、強化された設定管理システムです。おそらく最も典型的な環境構成は、開発環境（DEV）、テスト環境（STAGING）、エンドユーザー向けのライブサイトである本番環境（PROD）を持つことです。Drupal 8では、すべての設定をYAMLファイルとしてエクスポートし、別の環境にインポートできます。
個別のDEV、STAGING、PROD環境を使用する予定がある場合、可能なアプローチの1つを下の図に示します。Drupalエンティティを次のように分類できることを理解することが重要です：
- コンテンツオブジェクト（ユーザー、ノード、タクソノミー用語など）
- 設定オブジェクト（コンテンツタイプ、フィールド、ビュー、すべての設定パラメーター）
上の図のアップグレードプロセス：
1. Drupal 8 DEV環境がソースサイトからアップグレードされます。
2. ソースサイトはオンラインのまま維持されます（コンテンツが作成または更新される可能性があります）。同時に、Drupal 8 DEV環境で設定が完成します。
3. Drupal 8設定管理システムを使用して、設定をDEVからSTAGINGにデプロイできます。通常はバージョン管理システム（例：Git）が使用されます。
4. STAGING環境の設定が完了したら、最終受け入れテストのためにソースサイトからSTAGINGにコンテンツを移行できます。受け入れテストが問題なければ、Drupal 8 PRODサイトがデプロイされ、ソースサイトからDrupal 8 PRODサイトにコンテンツが移行されます。
このアプローチにはDrushを使用したアップグレードが必要です。このアプローチにはいくつかの可能なバリエーションがあります。
- 移行の生成方法については、Drushを使用したアップグレードページを参照してください。
- Drupal 8 DEVへのアップグレード（上の図のステップ1）は、drush migrate-import --allで全移行を実行するか、drush migrate-import <migration name>で必要な移行を1つずつ実行することで実行できます。
- コンテンツのみのアップグレード（上の図のステップ4）は、drush migrate:import --tag=Contentで全コンテンツ移行を実行するか、drush migrate-import <migration name>で目的の移行を1つずつ実行することで実行できます。また、目的の移行をマニフェストファイルに列挙することもできます。