コンテンツを本番サーバーから開発サーバーに移動するためのベストプラクティス
私はDrupal 7サイトを構築するためにGITを使用しました（ これらのガイドラインに従って ）。サイトを更新する前に変更されたコンテンツをダウンストリームに移動するために-新しい古いコンテンツのあるコンテンツ–そのためのベストプラクティスを知りたいのですが、d2d移行モジュールの使用を検討していましたが、確立された方法と実証済みの方法があるのでしょうか。
専門家はこれをどのように行うのですか？
データを失うことなく既存のプロジェクトを変更することは、一般的なニーズです。
機能を使用
私が知っているベストプラクティスの1つは、 機能モジュール を使用して、運用サーバーで行ったすべての変更を配信することです。機能を使用すると、コンテンツタイプの構造、ビューの定義などを含むカスタムモジュールを作成できます。
いくつかの部分の設定変数（たとえば、モジュール構成）を取得できるようにするには、おそらく Strongarm module も使用する必要があります。
これらのモジュールは、gitを使用していても、変更を本番サイトにデプロイするのに役立ちます。機能の使用に関する優れたチュートリアルを簡単に見つけることができます。
知っておくべき唯一の重要な部分は、機能の使用を開始したときに、使用を停止するのが難しいことです。 Webサイトのすべての仕様（コンテンツタイプ、フィールド、ビュー、ページなど）を含むカスタムモジュールを作成して実装するためです。それらを無効にすると、すべてが消えます。
エクスポートの変更
プロジェクトの変更が複雑にならない場合（主にコンテンツタイプの構造とビュー）、一部のモジュール（ビューなど）が提供するエクスポート/インポートの可能性を使用できます。
ノードコンテンツタイプのエクスポートおよびインポートパーツに バンドルコピーモジュール を使用することもできます。
ハードウェイ
あと、ときどき難しい使い方があります。既存のコンテンツタイプのフィールド設定を変更せず、一部（フィールドとコンテンツタイプ）を追加した場合にのみ機能します。
開発サーバーデータベースに、運用サーバーのコンテンツテーブルをコピーできます。すべてのコンテンツタイプ、特にそれらで使用されるフィールド（特にフィールドのマシン名）をよく理解している必要があります。
=>開発サーバーの新しいノードと変更されたノードがすべて失われます。次に、最初にデータベースのバックアップを作成することをためらわないでください。
その場合は、本番サーバーからすべてのコンテンツテーブルをコピーできます。
- node：すべてのコンテンツ情報を含むベースノードテーブル
- node_revision：リビジョン情報を取得したい場合
- コンテンツタイプフィールドのそれぞれについて：
- データテーブル：field_data_ [field_name]（ie：field_data_body）
- リビジョンテーブル：field_revision_ [field_name]（ie：field_revision_body）
- url_alias：コンテンツのカスタムパス（必要な場合）
- 分類表：必要な場合、ただし注意が必要な場合があります
- userテーブル：usersおよびusers_roles（必要な場合）
すべての提案をありがとう！
他の誰かが別の解決策を探している場合に備えて、私は自分の質問にこの回答を投稿することにしました。変更されたテーマ、新しい関数、カスタムモジュール、新しいコードなどで本番サイトを更新する必要がある場合、当面は次のようにします。
- PuTTYを使用してリモートの本番サーバーにログインし、Node Export module with Drush（> drush ne-export --type = mycontent_type --file = transfer /）を使用して各コンテンツタイプからすべてのノードをエクスポートしますmycontent_type.txt）。
- 各コンテンツタイプからすべてのノードをエクスポートした後、FileZillaを使用して、すべての（8）エクスポートファイルを含む転送フォルダーを開発サイトに転送します。
- 開発サイトでは、Drushを使用して、各コンテンツタイプのすべてのノードをインポートします。これらの3つのステップは、約1000ノードと8コンテンツタイプで約10〜15分かかります。
- 本番サイトと開発サイトのコンテンツはまったく同じです。必要に応じて、本番サイト/デフォルト/ファイルから開発者側にもイメージを転送します。これにより、すべてが同じに見えることを簡単に確認できます。
- 開発サイトでは、移行とバックアップを使用してデータベースをバックアップしています。本番ブランチで、ローカルの変更をGitHubリポジトリに追加、コミット、プッシュします。
- 次に、PuTTYを使用してステージングサイトにログインし、Githubから本番ブランチを取得します。
- ステージングサイトで、バックアップと移行を使用して、手順5のデータベースバックアップを復元します。
- すべてが良さそうであれば、本番サイトをメンテナンスモードにして、そこでステップ6と7を繰り返します。
このようにして、開発側にライブコンテンツの新しいコピーを作成します（コンテンツをいつでも簡単にダウンストリームに移動できます）。
提供された回答については、機能モジュールと提案された他の可能性を確実に探ります。再度、感謝します。そして、あなたが私の現在の方法に欠陥を見つけたら、私に知らせてください。
たぶん、ライブサイトで新しいコンテンツを追加したり変更したりすることが許可されている人はごくわずかであることを言及しておきます。つまり、更新手順中に新しいコンテンツの変更が行われないことがわかります。
D7はその構成をsqlに保持するため、本番環境からdevにsql-syncすると（以下で説明）、devに加えられた構成の変更はすべて上書きされます。 （これはDrupal 8で修正されており、構成はコンテンツとは別に保存されます。）
機能を使用して、devで行われたデータベース構成の変更をSQLデータベースの外部のファイルにプッシュすることをお勧めします。次に、本番環境にファイル同期し、データベースに再インポートできます。残念ながら、既存のサイトを改造して構成に使用する機能であり、すべてのモジュールがサポートしているわけではありません機能。一部の人々はこの方法で成功していると報告していますが、私はそれを私のサイトで機能させることができませんでした-YMMV。
代わりに、これを行う方法は、開発サイトに対して行ったすべての構成変更と追加のかなり詳細な日記を保持することです。 sql-syncの後、この日記をscriptとして使用し、これらの構成変更を手動でdevに追加します。
両方のサーバーで同じコードベースを実行しているため、d2d migrationまたはその他のモジュールを使用する必要はありませんSQLデータベースを移行するには-標準のシェルツールで実行できます。
Drupalを保持するデータベースの名前が "drupal7 "：
最初にすべてのキャッシュをクリアし（ダンプのサイズを小さくするため）、次に "drupal7 "本番サーバー上のDB：
drush cc all
mysqldump -u root -p drupal7 > productionYYMMDD.sql
次に、（scpを使用して）ダンプファイルを本番環境から開発に移動し、完全なダンプを開発サーバーに挿入します。
mysql -u root -p drupal7 < productionYYMMDD.sql
（ダイアリーをスクリプトとして使用して）手動で構成変更を追加した後、devをデプロイする準備が整いました。
Gitは、コンテンツではなくコードの同期に使用されるため、ここでは関係ありません。