新しいコンテンツを失うことなく、サイトの開発コピーからライブサイトに変更をマージするにはどうすればよいですか？

サイトの開発コピーで行われた作業をライブ運用コピーにマージするための最良の手順は何ですか？多くの場合、最新の機能の開発が開始されてから、サイトに多くの新しいコンテンツが追加されています。また、サイトへのほとんどの追加にはデータベースの変更が含まれます。新しいファイルをコピーするのは簡単ですが、データベースはどうですか？運用サイトを最後に更新してから追加された新しいコンテンツを失うことなく、既存の運用データベースに変更をどのようにマージしますか？これに役立つモジュールはありますか？

開発サイトのコンテンツタイプ、ビュー、および構造の変更については、機能を使用してデータベースをコードにエクスポートする方法を参照してください。

コンテンツの移行には多くのオプションがありますが、単一のソリューションではありません。1つの例は、展開スイートです。

ここでは基本的に2つの考え方を採用しました（データベースの差分をとる3番目の考え方です。複雑さが非常に高いため、説明しません）。

1）本番データベースを削除して展開し、開発データベースのmysqldumpをインポートします。オプションで、SQLダンプ内のdev URLを参照するハードコーディングされた絶対リンクで、事前に正規表現の検索/置換を実行します。dev dbをprodにインポートした後、自動的にSQLステートメントを（通常はスクリプトを介して）実行して、devとは異なるprodの設定を変更します（たとえば、必要な外部システムに接続するための接続設定を変数テーブルに持っている場合devバージョンではなくprod外部システムを指すように変更します）。

2）buddaが述べたように、管理設定に機能モジュールを使用し、コンテンツのエクスポート/インポートにノードエクスポートモジュールを使用して、すべて削除モジュールを組み合わせます。ワークフローは次のとおりです。

1. node_exportおよび機能を使用して、ノード/機能をファイルにエクスポートします
2. オプションで（できれば）バージョン管理
3. 製品システムにファイルをロードする
4. 機能をロードするには、drushまたはadminインターフェイスを使用します
5. drush delete-allまたはadminインターフェイスを使用して、インポートするタイプのすべてのノードを削除します
6. drush ne-importまたは管理インターフェイスを使用して、エクスポートしたノードファイルからノードをインポートします。

1つの注意点として、コンテンツが一方向にのみ流れる標準ワークフローを採​​用することを強くお勧めします。Dev-> ProdまたはProd-> Devのいずれか（私はこれを好みます）。

私はこれを行っており、いくつかの大きなシステムでこれを行っていますが、かなり良い結果が得られていますが、このリンゴをスライスする方法は常にたくさんあります。

SQLファイルのサイトのライブサイトコピーと開発コピーのデータベースをダンプします（両方のダンプに同じパラメーターと設定を使用します）。
次に、小さな比較ツールExamDiffを使用して両方のSQLファイルを比較します。ファイルの違いを異なる色で並べて表示します。スクロールせずに、違いに直接ジャンプすることもできます。違いを調べて、ライブサイトのSQLファイルに行を追加/編集します。そのファイルに開発環境の絶対パス/ URLがないことを確認してください。完了です！ライブサイトのデータベースを復元する時間。
あなたの人生を楽にします：最初のステップでは、変更されたテーブルのみをダンプします。たとえば、別のテーブルを対象とする開発コピーのモジュールを編集した場合、このテーブルのみをダンプします。特定のテーブルがわからない場合は、データベース全体のダンプで問題ありません。