53

私は MacBook で XAMPP の最初の Drupal プロジェクトに取り組んでいます。これはプロトタイプであり、クライアントから肯定的なフィードバックを受けています。

2 週間後にプロジェクトを Linux VPS にデプロイします。サーバー上のすべてを最初から「やり直す」よりも良い方法はありますか?

  • Drupalをインストールする
  • モジュールのダウンロード (CCK、Views、Date、Calendar)
  • コンテンツを作成する
  • ...

ありがとう

4

9 に答える 9

21

機能.module は、Drupal 構成の変更を管理するための非常に強力なツールです。

コンテンツ タイプ、CCK 設定、ビュー、Drupal 変数、コンテキスト、イメージキャッシュ プリセット、メニュー、タクソノミー、およびアクセス許可はすべて、バージョン管理にチェックインできる機能にまとめることができます。そこから、新しいサイトを展開したり、既存のサイトに変更をプッシュしたりすることは、機能 UI または Drush を使用して簡単に管理できます。

変数テーブルに保存される drupal 構成をエクスポートするために、必ず Strongarm.module をインストールしてください。uuid_features.module をインストールすることで、コンテンツ/ノード (つまり、私たちについて、よくある質問など) を機能に静的にすることもできます。

間違いなく、これは同じサイトで他の開発者と協力し、サイトを開発からテスト、ステージング、本番に移行するための最良の方法です。

于 2011-01-29T21:43:45.740 に答える
16

これについて私の職場で広範な議論を行い、最終的に落ち着いた方法は、コードの更新 (モジュールとテーマを含む) を開発からステージング、さらには本番環境にプッシュすることでした。これには Subversion を使用しており、これまでのところうまく機能しています。

特に重要なのは、データベースを本番環境からプッシュバックするプロセスを自動化して、開発者がデータベースのコピーをできるだけ本番環境に近づけることができるようにすることです。ミッション クリティカルな環境では、モジュールの更新によってデータベースに問題が発生しないことを絶対に確認する必要があります。私たちが使用するプロセスは次のとおりです。

  1. モジュールを開発サーバーにインストールします。
  2. 必要な変更や更新をメモしておいてください。問題が発生した場合は、元に戻して、確実でエラーのないプロセスになるまで繰り返します。
  3. 変更をテストしてください。通常のログイン ユーザーとしてテスト プロセスを繰り返し、再び匿名ユーザーとしてテスト プロセスを繰り返します。
  4. 更新プロセスに update.php の実行以外の何かが含まれる場合は、それを実行するためのスクリプトを記述します。
  5. 運用データベースをステージング サーバーにコピーし、同じ手順をすぐに実行します。失敗した場合は、失敗を診断して手順 1 に戻ります。それ以外の場合は続行します。
  6. 変更をテストしてください。
  7. 本番データベースをバックアップし、SVN からチェックアウトしたリビジョンをメモします。
  8. プロダクション Drupal をメンテナンス モードにして、プロダクション ツリーで「svn update」を実行し、アップデート プロセスを実行します。
  9. Drupal をメンテナンス モードから外し、すべてをテストします (管理者、通常のユーザー、および匿名として)

以上です。Drupal などのコミュニティ フレームワークに期待できないことの 1 つは、稼働後にデータベースをテストから運用に移行できることです。それ以降、すべてのデータベースの移動は本番環境からテスト環境へと移行するため、展開プロセスが多少複雑になります。気をつけて!:)

于 2009-05-20T15:57:33.567 に答える
5

誰もDeploymentモジュールについて言及していないことに驚いています。プロジェクトページからの抜粋は次のとおりです。

...ユーザーが1つのDrupalサイトから別のサイトにコンテンツを簡単にステージングできるように設計されています。Deployは、エンティティ間の依存関係(ノード参照など)を自動的に管理します。さまざまなコンテンツステージング状況で使用するために簡単に拡張できる豊富なAPIを持つように設計されています。

于 2010-01-15T07:31:01.923 に答える
5

Features モジュールを広範囲に使用して機能をキャプチャし、運用サイトに簡単にインストールします。

于 2010-01-15T09:34:39.383 に答える
2

任意のバージョン管理システム(GIT、SVN)+ Drupalコードをデプロイするための機能モジュール+カスタム設定(コンテンツタイプ、カスタムフィールド、モジュールの依存関係、ビューなど)。

デプロイモジュールはまだ開発モードであるため、Drupal7のノードエクスポートモジュールを使用してコンテンツ/ノードをデプロイすることをお勧めします

于 2013-01-21T07:53:02.620 に答える
2

Drupal は使用しませんが、Joomla はよく使用します。すべてのファイルを Web ルート (私の場合は tar と gzip ですが、zip を使用することもできます) にアーカイブし、そのアーカイブを運用サーバーにアップロードして展開することでデプロイします。次に、SQL ダンプ (mysqldump -u user -h host -p databasename > dump.sql) を取得してアップロードし、リバース コマンドを使用してデータを挿入します (mysql -u produser -h prodDBserver -p prodDatabase < dump.sql)。 )。シェルにアクセスできない場合は、ファイルを 1 つずつアップロードし、PHP スクリプトを記述して dump.sql をインポートできます。

于 2009-04-08T14:07:54.130 に答える
0

私が見つけて現在実装している優れた戦略は、デプロイモジュールの組み合わせを使用してコンテンツを移行し、次にdbscriptsと一緒にダッシュして、コアとモジュールをマージおよび更新することです。ライブコンテンツ、セキュリティ、モジュールの更新がある場合でも、データベースのマージを処理します。現在、svnで動作するように設定しています。

于 2010-03-11T18:26:46.723 に答える
0

デプロイ (または Drupal) が初めての場合は、必ずすべてを一度に行ってください。別のコピーで作業しているときにコンテンツに影響を与えるユーザーがいる場合は、十分に注意する必要があります。

構造ではなく、実際のコンテンツ、分類法、ユーザーなどに関連するテーブルを残すことができます。次に、構成に関連するものをプッシュします。ただし、これにより、桁違いの複雑さが追加されます。

展開があなたにとって古い帽子である場合は、お詫び申し上げます。したがって、これは漠然と侮辱的です。

于 2009-04-23T07:04:49.157 に答える