新しいコンテンツを失うことなく、サイトの開発コピーからライブサイトへの変更をどのようにマージしますか？
サイトの開発用コピーで行われた作業をライブの本番用コピーにマージするための最良の手順は何ですか？最新の機能の開発が開始されてから、多くの場合、サイトに多くの新しいコンテンツが追加されています。また、サイトへのほとんどの追加には、データベースの変更が含まれます。新しいファイルをコピーするのは簡単ですが、データベースはどうでしょうか？最後に本番サイトを更新してから追加された新しいコンテンツを失うことなく、既存の本番データベースと変更をどのようにマージしますか？これに役立つモジュールはありますか？
開発タイプサイトのコンテンツタイプ、ビュー、および構造の変更については、データベースをコードにエクスポートするために Features を使用することを検討してください。
コンテンツの移行には多くのオプションがありますが、単一のソリューションではありません。 1つの例は Deployment suite です。
私は基本的にここで2つの考え方を採用しました（3番目の考え方、データベースの差分を行う、複雑さが非常に高いため、説明しません）。
1）本番データベースを削除し、開発データベースのmysqldumpをインポートしてデプロイします。必要に応じて、SQLダンプの開発URLを参照するハードコードされた絶対リンクに対して、事前に正規表現検索/置換を実行します。 dev dbをprodにインポートした後、SQLステートメントを（通常はスクリプトを介して）自動的に実行し、devとprodで異なる設定を変更します（たとえば、変数テーブルに、必要な外部システムに接続するためのいくつかの接続設定がある場合があります） devバージョンではなく、prod外部システムを指すように変更します）。
2）buddaによって言及されているように、管理設定には Features モジュールを使用し、 Node ExportDelete All モジュールと組み合わせたコンテンツのエクスポート/インポートモジュール。したがって、ワークフローは次のとおりです。
- node_exportとfeaturesを使用して、ノード/機能をファイルにエクスポートします
- オプションで（できれば）バージョン管理
- Prodシステムにファイルをロードする
- Drushまたは管理インターフェイスを使用して機能をロードする
- Drush delete-allまたはadminインターフェースを使用して、インポートするタイプのすべてのノードを削除します
- Drush ne-importまたは管理インターフェイスを使用して、エクスポートしたノードファイルからノードをインポートします。
1つの注意点として、コンテンツが一方向のみに進む標準ワークフローを採用することを強くお勧めします。 Dev-> ProdまたはProd-> Dev（私はこれが好きです）。
私はこれを実行しましたが、いくつかの大きなシステムでこれを実行していますが、かなり良い結果が得られていますが、このAppleをスライスする方法は常に数多くあります。
ライブサイトコピーとサイトの開発コピーのデータベースをSQLファイルにダンプします（両方のダンプに同じパラメーターと設定を使用します）。
次に、小さな比較ツール ExamDiff を使用して、両方のSQLファイルを比較します。ファイルの違いを異なる色で並べて表示します。 （スクロールせずに）直接相違点にジャンプすることもできます。違いを調べて、ライブサイトのSQLファイルに行を追加/編集します。そのファイルに開発環境の絶対パス/ URLがないことを確認してください。できました！ライブサイトのデータベースを復元する時間。
人生を楽にします：最初のステップでは、変更されたテーブルのみをダンプします。たとえば、別のテーブルをターゲットとする開発コピーのモジュールを編集した場合、このテーブルのみをダンプします。特定のテーブルが不明な場合は、データベース全体のダンプで問題ありません。