ステージングサーバーからライブサーバーへのコンテンツ更新の展開

コンテンツの更新をステージングサーバーからライブサーバーに展開しようとしていますが、これを行うための適切な方法を見つけるのが困難です。新しいページ、ページの更新、場合によってはページの削除をデプロイできる必要があります。私たちのサイトでは、bookモジュールも多用しているため、現時点ではDeployモジュールは機能しません。大規模な構造の更新に機能を使用しています。したがって、私たちの懸念は、毎日のコンテンツの更新だけです。

これを実行して本のページを処理できるモジュールはありますか？

UUIDとUUID機能を使用すると、ノードを機能にエクスポートできます。これは、目的の機能である可能性があるため、データベースをいじる必要がないことを意味します。

あなたがしようとした持ちnode_exportおよびバックアップ移行。両方のモジュールは、Drupalインストール間でコンテンツを移行するために使用されます。以下は、役立つと思われるデータのインポート/エクスポートモジュールの比較です。

ここではDrupal 6を想定していますが、本モジュールで動作するかどうかは個人的にはわかりませんが、デプロイメントについて調べましたか？

また、自動的にPhingを試すこともできます。

• mysqldumpを使用してステージングデータベースをダンプします。
• SCPおよび公開秘密鍵暗号化を使用して、mysqldumpファイルをあるサーバーから別のサーバーにコピーします。
• mysqldumpをファイルシステムからデータベースにインポートします。
• Feature Revert Allコマンド（drush fra -y）を実行して、本番サーバーがフィーチャーコードにある本番設定（ブロック、ビュー、コンテキストなど）を取得するようにします。

このアプローチで私が見る問題：

非常に細かいデータベースのエクスポートを行う必要があります。つまり、node、node_revisions、cck、およびmenuテーブルのみを取得します。

最後のポイント（メニューリンク）では、同じURLエイリアスを使用してステージサーバーと製品サーバーの両方にアクセスしない限り、メニュー項目のエントリが異なり、これは深刻な問題になります。

完全なDBダンプメソッドが実際に好きです。スクリプトで作成でき、多くの場合、ほんの数秒で完了します。（リビジョンを管理し、キャッシュテーブルなどを除外すると、サイズを大幅に削減できます。）単純なモジュールを作成して、コンテンツ発行者がこのプロセスをトリガーするためのインターフェイスを提供することもできます。

コメントやコンタクトフォームの送信など、ライブサイトのユーザーから受け入れる可能性のあるすべてのコンテンツを考慮する必要があります。存在する場合-驚くほど頻繁に存在しない場合-コメントにDisqusやリード生成フォームにMarketoなどの外部サービスを使用するか、そのような送信を、上書きされない別のDrupalデータベースに慎重に分離するか、それらを慎重に上書きしないでください。エクスポート/インポートプロセス中に影響を受けるテーブル。

それを機能させることができるところでは、それは結局最も単純で、最も速く、最も信頼できる方法になるかもしれません。また、（外部サービス以外の）ユーザーからの入力を決して受け付けないサイトは、より高速で安全なサイトにするための多くの扉を開きます。