1

SO、ブログ投稿、フォーラムなどに関する質問を2日間読んでいます。

その情報のほとんどは、古いものです。

Drupal 7（Drushを使用）とリポジトリホスティング用のGitHubを使用して、Ubuntuボックスにサイトを構築しています。本番サーバーへのSSHアクセスがあります。

サイトの最初のバージョンを配信した後、機能を追加してバグを修正する必要があります。

友人から、SQLファイルをリポジトリに保存してそこから移動するように言われました。

私の質問は：最良のアプローチは何ですか？これについての良い習慣のアドバイスはありますか？

ありがとう！

4

2 に答える 2

1

私は Drupal の専門家ではありませんが、一般的にデータベースのデプロイは注意が必要です。特に、最終的に変更を注文する必要があるため、テスト環境と本番環境になる場合はなおさらです。必要なデータベースの更新を実行する何らかの形式の「マスター スクリプト」を使用することをお勧めします。データベースにどのバージョンを使用しているかを尋ねるクエリでラップし、新しい SQL 更新のみを適用します。

于 2011-08-25T19:22:54.790 に答える
0

Drupal自体には構成管理の一般的なトピックに対する適切な答えがないため、Drupalでのデプロイメントは複雑なテーマです。Drupal 8がそこに到達するための主要なイニシアチブは大きな進歩を遂げましたが、今のところ、データベースに保存されているコンテンツと構成の両方の厄介さに対処しています。

最低限、コンテンツ用のデータベースダンプが必要になります。そこから、それは潜在的なエッセイのシリーズ全体になります。いくつか触れてみましょう：

  • モジュールで更新フックを使用して、展開ワークフローの一部としてデータベースの変更を管理します。
  • exportables / everything-in-codeアプローチを使用します。このアプローチでは、データベースの構成タイプのビットがサイトカスタムモジュールの一部としてPHPコードとしてエクスポートされます。リンクするのに適したページを見つけるには、これを行うためのさまざまな方法が多すぎますが、機能モジュールを使用しています。
  • rsyncのラッパーとしてdrushを使用して、サイトエイリアスなどのツールを使用してデプロイメントとデータ転送を管理できるようにします。Drushは素晴らしいツールです、ただそれを掘り下げ続けてください。

SQLをリポジトリにダンプすることはできますが、バージョン管理するすべての構成がコードにエクスポートされるため、必要ではありません。したがって、SQLダンプは実際にはバックアップに相当します。

于 2012-03-29T21:08:29.110 に答える