テスト環境から本番環境に移行するにはどうすればよいですか？
移行は、ローカル環境から本番環境へです。本番環境はしばらく稼働しており、多くの記事を作成しています。
私のサイトに新しいものを追加するために、カスタムテーマを追加し、CCK、ビュー、その他のモジュールをローカルテスト環境にインストールしました。ローカルテスト環境が完成したので、データベースのコンテンツを破壊せずに、どのようにして本番環境に移行しますか？
これは重要な問題であり、ほとんどすべての人が異なる答えを持っています。本番プッシュへのステージングを処理する標準的なDrupal方法はありません。 Drupalショーを運営しているDries Buytaertが Drupal 8 の主要な取り組みの1つにした。もちろん、Drupal 7がリリースされたばかりなので、それが実を結ぶまでにはしばらくかかります。
この問題は、次の2つの問題に分けられます。
- ステージング構成（変数、コンテンツタイプ、フィールド、ビューなど）
- ステージングコンテンツ（ノード、ユーザーなど）
前者は主に Features モジュールで処理できます。これは、サイトの構成を取得して、Drupalインストールに追加できるモジュールに変換します。この方法で、バージョンコントロールに追加できます。コンテンツを移行するときにシステムが吹き飛ばされることを心配する必要はありません。
後者は実際には注意が必要です。アクティブなサイトでは、開発環境に最初に同期した後でも、本番環境ではコンテンツが変更される可能性があるためです。これにより、構成で行うことができるような、ステージング中のコンテンツの大規模な置換が防止されます。
また、Drupalはコンテンツにユニバーサル一意識別子（UUID）を使用しません。ノードまたはユーザーが追加されるたびに、IDが1ずつ増加します。したがって、開発サイトのノード45は本番サイトのノード90になる可能性があります。
残念ながら、これに対する優れた解決策はありません。ステージングコンテンツはDrupalの本当の弱点です。私が個人的にしているのは、制作サイトにのみコンテンツを追加することです。クライアントがコンテンツを公開する前にどのように見えるかを確認したい場合は、クライアントのみがアクセスできる本番サイトのクローンを設定します。次に、承認されると、同じ変更が直接本番環境に加えられます。
別の方法があります： Deploy モジュール。ステージングコンテンツを比較的苦痛なくするために Services を活用することになっています。しかし、その有効性を保証できず、Drupal 7バージョン。
私たちのプロセスでは。
- Prodからdbをプルするシェルスクリプトがあります。
Hudsonを使用してdev/stagingブランチを再構築し、ライブブランチとdevブランチを同期しています。
Gitを使用しているため、実行するすべてのタスクには独自のブランチがあり、QAに渡されると、それをマージして、回帰テスト用のステージングサーバーとしてマスターにします。
マスターの準備ができたら、ライブ（構成、ハードウェアなど）のレプリカである
Release Serverにテストリリースを行います。Featureモジュールを使用して構成をデプロイします。一部の機能はまだ機能でサポートされていないため、hook_update_Nを使用してから、updatedb.phpまたはdrush -vd updbを実行します- リリース後、機能revert（
drush fra --yes）を実行して、オーバーライドされたすべての機能を元に戻します。 Boost（Varnishに移動）とMemcacheを使用しているので、キャッシュ（
drush cc all）をクリアする必要があります。Rsyncを使用して画像/ビデオなどを同期しています...
XAMPPサーバーから別のサーバーに移行するために、 this site の指示に従いました。
本番サーバーでも、開発サーバーと同じ構造を維持するようにしてください。 Drupal管理ダッシュボード：admin/config/media/file-system
Public file system pathおよびTemporary directoryに正しい場所が設定されていることを確認します。