33

標準の php またはソース コード ベースのプロジェクトでは、すべてのコードを SVN に簡単に保持し、各開発者は自分のコピーをチェックアウトして、同じコードで共同作業できます。

ただし、Drupal サイトを開発する場合、作業の多くは「セットアップ」にあります。テーマとモジュール以外に、実際には「ソースコード」はありません。同じサイトの複数のインスタンスを実行して、開発者全員が同時に作業しながら作業を共有できるようにするにはどうすればよいでしょうか?

シナリオ例:

コンテンツ タイプ「X」を作成した Drupal サイトの初期バージョンを立ち上げます。また、最初に、タイプ「X」のすべてのノードを時系列でリストするサイトのビューを起動します。クライアントはサイトの使用を開始し、コンテンツ、メニュー項目などを追加します.

次のリリースでは、そのビューにユーザー検索機能を追加する予定です。ただし、そのためのセットアップはデータベースに含まれています。ビューの変更作業中に、運用データベースを開発バージョンにコピーして最新のデータを取得できます。ただし、その間、クライアントはまだサイトを更新している可能性があり、開発データベースが同期しなくなります。新しいビューを本番環境にプッシュする準備ができたら、手動で手順を繰り返して本番環境にセットアップする以外に、より簡単な方法はありますか?

4

7 に答える 7

12

ここでの良い戦略は、インストール プロファイル API を使用することだと思います。インストール プロファイル API を使用すると、Drupal 管理ツールを使用してできることのほとんどを行うことができます。ほとんどのコア フォームは、変数テーブルに変数を設定するだけです。コンテンツ データベース以外のコンテンツ、つまり構成を適切にバージョン管理できるようにするには、更新機能を使用するのが賢明です。

私のサイトでは、ec.install ファイルに ec_update_6001() などの更新関数が含まれていることを除けば、ほとんど機能しないモジュール「ec」があります。

メインのインストール機能は、モジュールを最新にするために作成した新しいインストールで実際に更新を実行することを処理できます。

function ec_install() {
  $ret = array();
  $num = 0;
  while (1) {
   $version = 6000 + $num;
   $funcname = 'ec_update_' . $version;
   if (function_exists($funcname)) {
     $ret[] = $funcname();
     $num++;
   } else {
     break;
   }
  }
return $ret;
}

実際のファイルからの更新関数のサンプルが 1 つまたは 2 つ続きます。

// Create editor role and set permissions for comment module
function ec_update_6000() {
  install_include(array('user'));
  $editor_rid = install_add_role('editor');
  install_add_permissions(DRUPAL_ANONYMOUS_RID, array('access comments'));
  install_add_permissions(DRUPAL_AUTHENTICATED_RID, array('access comments', 'post comments', 'post comments without approval'));
  install_add_permissions($editor_rid, array('administer comments', 'administer nodes'));
  return array();
}
// Enable the pirc theme.
function ec_update_6001() {
  install_include(array('system'));
  // TODO: line below is not working due to a bug in Install Profile API. See http://drupal.org/node/316789.
  install_enable_theme('pirc');
  return array();
}

// Add the content types for article and mtblog
function ec_update_6002() {
  install_include(array('node'));
  $props = array(
    'description' => 'Historical Movable Type blog entries',
  );
  install_create_content_type('mtblog', 'MT Blog entry', $props);
  $props = array(
    'description' => 'Article',
  );
install_create_content_type('article', 'Article', $props);
return array();
}

これにより、データベースと Drupal コードのバージョン管理の問題が実質的に解決されます。私たちはそれを広く使用しています。これにより、データベースを再インポートしたりライブで変更したりすることなく、データベース構成を変更する新しいコードを促進できます。これはまた、隠れたデータベースの変更を恐れることなく、リリースを適切にテストできることを意味します。

最後に cck とビューがこのアプローチをサポートしています。このコード スニペットを参照してください

// Enable CCK modules, add CCK types for Articles in prep for first stage of migration,
// enable body for article, enable migration modules.
function ec_update_6023() {
  $ret = array();
  drupal_install_modules(array('content', 'content_copy', 'text', 'number', 'optionwidgets'));
  install_include(array('content', 'content_copy'));
  install_content_copy_import_from_file(drupal_get_path('module', 'ec') . '/' . 'article.type', 'article');
  $sql = "UPDATE {node_type} SET body_label='Body', has_body=1
  WHERE type = 'article'";
  $ret[] = update_sql($sql);
  return $ret;
} 
于 2009-01-05T20:43:50.197 に答える
11

少し前に、CVS と Subversionのベスト プラクティスを使用した簡単な Drupal リビジョン コントロールに関する記事を書きました。

残念ながら、ご指摘のとおり、データベースのソース管理の問題がまだ残っています。追加の投稿で言及するいくつかの推奨される方法があります。

于 2008-11-12T03:33:37.980 に答える
7

Drupalの設定をデータベースからコードに取り込むことは、飛躍的に進歩していました。この領域で本当に役立つ2つのモジュールは次のとおりです。

機能-コンテンツタイプ、分類法、ビュー、さらにはフィードなどのエンティティをまとめることができます。私たちはこれを非常にうまく使用しており、開発者間でこれらの変更を共有することが可能になりました。

Strongarm-上記のモジュールを使用して変数の保存とエクスポートを可能にします。私はこのモジュールでいくつかのテストを行いましたが、実際には機能を必要としなかったため、単純に使用していません。

これらは、データベースにサイトのセットアップを維持することに関する最大の問題を解決します。ただし、完全ではありません。。。サポートされていない、または正しくサポートされていないモジュールが見つかりました。

于 2010-07-10T00:30:51.427 に答える
1

CCKやViewsなどの一部のモジュールでは、セットアップデータをテキストとしてエクスポートおよびインポートできます。これらのテキスト表現は、ソース管理システムの下に保存できます。

于 2008-12-16T15:42:58.223 に答える
1

残念ながら、ここには良い/単純な解決策はありません。この問題は、Drupal だけでなく、すべてのフレームワーク タイプの CMS のアーキテクチャの残念な副作用です。アプリケーションは、ソース コードと同様に構成 (つまり、データベースに格納されたデータ) によって定義されます。構成データを管理するための 2 つのオプションはどちらも優れたものではありません。1つ目は、あなたがしていることです: 単一のデータベースを正規 (つまり、本番データベース) として定義し、開発者に本番データベースのスナップショットをローカルで使用させ、本番サイトからの手動構成を介して新しい構成情報を本番データベースに「マージ」します。管理インターフェース。明確に定義されたサブシステム (つまりビュー) の場合、この種の構成の移行を容易にするために開発されたインポート/エクスポート機能を利用できる場合があります。2番目のオプション-つまり あなたが探していると思う自動化 - 難しいですが、それだけの価値がある - または必要です - 複雑なプロジェクトの自動化のための予算を持つ大規模なプロジェクトの場合: システム/モジュールのデータベース構造を深く掘り下げ、新しい構成データをマージするためのカスタム スクリプトを開発します。たとえば、最新のデータベースの夜間の「ビルド」の一部として、テーブル/レコードレベルを本番データベースに追加します。間に解決策がないことを恐れています。

構成データの履歴を追跡するためのバージョン管理に関しては、backup_migrate のようなモジュールを使用すると、データベースの自動 SQL ダンプを実行できます。バックアップ「プロファイル」を定義することで、どのテーブルをダンプするかを選択できます。また、ダンプから大きなコンテンツ、ロギング、およびキャッシュ テーブル (node、cache_content、watchdog など) を残すテーブルを作成できるため、バージョン管理用により管理しやすいチャンクが残されます。 . サーバーまたは他の場所で簡単なスクリプトを実行すると、最新のダンプを取得してリポジトリに追加できます。

于 2011-04-07T16:11:25.820 に答える
1

svn:externalsプロパティを使用すると、Nick の記事で説明されているように、SVN を構成して操作する手間を省くことができます。これにより、Drupal のローカル バージョンが指定された Drupal ブランチで自動的に最新の状態に保たれ、モジュールに対してまったく同じメカニズムを使用できます。さらに、SVN は外部定義をファイルから読み取るため、これらもバージョン管理下に置くことができます!

CVS に同等の機能があるとは思いません。ただし、Drupal モジュールを自動的にインストールする単純なスクリプトを作成するのは非常に簡単で、URL だけを取得します (私は自分の Drupal サイトを最新の状態に保つためにこれを行いました)。

データベースのバージョン管理に関する限り、これは解決するのが非常に難しい問題です。「ストック」の Drupal データベースを SQL ファイルにエクスポートし、それをバージョン管理下に置くことをお勧めします。各開発者は、使用する独自のローカル プライベート データベース サーバーを持っています。次に、指定したデータベースを SQL ファイルに含まれるストック バージョンに戻すスクリプトを提供できます。

この問題が他の方法でどのように解決されるかの例として、職場での状況を説明します。私は Web アプリケーションに取り組んでいます。データベースを使用しないため、これらの問題は発生しません。サイトの繰り返しセットアップを回避するための私たちの方法は、ソース管理から再構築し、サイトの自動展開を実現するプログラムを提供することです。このプログラムは、サイトを作成する方法としてお客様にも使用されています。

于 2008-11-13T21:12:33.000 に答える
0

Drupal は、ほとんどのサイト構成をコードに移動できるエクスポート可能な構成をサポートするようになりました。機能モジュールの助けを借りて、構成変数、ビュー、コンテンツ タイプ、フィールド、入力形式などのエクスポート可能ファイルがサポートされています。

また、中央のコントローラプロファイルまたはモジュールを使用して、初期のエクスポート不可能な構成と構成の変更を管理することもできます。モジュールの有効化、ユーザーの作成などに使用します。

Drupal における開発 -> ステージング -> プロダクション ワークフローの問題コード駆動型開発: Drupal 6 および 7 のプレゼンテーションで機能を効果的に使用するを参照してください。

于 2011-04-07T18:58:58.153 に答える