web-dev-qa-db-ja.com

Drupalサイトで共同開発を管理するにはどうすればよいですか?

私はDrupalサイトで他の開発者と協力しています。サイトのさまざまな部分で同時に作業することなく、サイトのさまざまな部分で作業するための良い方法を見つけるのに苦労しました。サイトの同じ開発インスタンスで作業しますが、互いにつま先を踏んだり、いくつかの不良コードでサイトを停止したりして、解決されるまで他のユーザーが作業を続行できないようにします。そのため、個別の開発インスタンスに移動しました。しかし、今では、作業をサイトの単一のインスタンスにマージするのは大変なことです。

現在私たちが抱えている最大の問題は、データベースの変更をどのようにマージするか、そしてデータベースをソース管理システムにどのように含めるかです。ファイルは簡単で、すべてを追跡し(gitを使用)、作業をマージして、必要に応じて競合を解決します。しかし、これは実際にはデータベースでは機能しません。 SQLダンプを取得してgitリポジトリに含めることはできますが、実際にデータベースをマージすることはできません。 機能モジュール は少し役立ち、データベース作業の一部をコードにエクスポートして、バージョン管理およびマージできるようにします。ただし、すべてに近いものでも機能をサポートしているわけではありません。そう...

  • データベースの変更を簡単にマージするには、どのような手順を実行できますか?

  • データベースをどのようにバージョン管理する必要がありますか(ダンプファイルをgitに配置するのは良い方法です)。

  • これらの問題のいくつかに役立つ利用可能なモジュールはありますか?

  • または、同じサイトのコピーで作業をしているのですか? (そうしないでください)


編集:コメントで、フィーチャーでエクスポートできないものについて説明しましたが、そのうちの1つが分類法でした。別の それを扱う質問 があります。

12
Chaulky

これはワークフローの変更ですが、ライブDBの新しいダンプでの作業に慣れる必要があります。 DBに変更を加える方法は3つあります。

  1. 特徴。これはすべてでは機能しませんが、必要な多くの機能で機能します。
  2. 更新フック。機能が機能しない場合は、所有するモジュールの更新フックにハードコードできます。
  3. 手動変更。控えめに使用してください。機能や更新フックに自然にもたらされないものもあり、手動で行う方がはるかに簡単です。これは最後の手段ですが、時には唯一の海賊的な方法です。

できれば。 1日に数回、新しいダンプを取得してビルドをテストすれば、統合の問題が少なくなるはずです。

5
Jeremy French

私は同様の質問に答えました。ここであなたの質問に答えるために少し調整します。私の根本的な提案は、継続的インテグレーションシステムを頻繁に(たとえば、5分ごとに)使用してコードの変更がチェックアウトされる開発/ステージングサーバーがあることです。したがって、ローカルマシンでは、一度に1つの機能リクエスト/バグレポートのみを処理します。他のユーザーからこのタスクを明確に説明し、作業中のチームメイトとやり取りしている(レッドマインまたはレッドマインまたは他のバグ追跡はこれに最適です)。次に、定期的に変更をコミットします。変更は、チームメイトと同様に、開発/ステージングサーバーにプルダウンされます。理想的には、継続的インテグレーションシステムにユニットテストが組み込まれていることです(ちなみに、これにはluntbuildまたはQuickBuildを強くお勧めしますが、Hudsonも機能します)。 CIシステムまたはテストは、コードをチェックインするとすぐに、発生した可能性のある競合を自動的に検出できます。コンテンツ(非コード)を変更する必要がある場合は、開発/ステージングサーバーで行います。

データベース部分については、ここでは基本的に2つの考え方を採用しました(3番目の考え方、データベースの差分を行う、複雑さが非常に高いため、説明しません)。

1)本番データベースを削除し、開発データベースのmysqldumpをインポートしてデプロイします。必要に応じて、SQLダンプ内の開発URLを参照するハードコードされた絶対リンクに対して、事前に正規表現検索/置換を実行します。 dev dbをprodにインポートした後、SQLステートメントを(通常はスクリプトを介して)自動的に実行し、devとは異なるprodの設定を変更します(たとえば、変数テーブルに、必要な外部システムに接続するためのいくつかの接続設定がある場合があります) devバージョンではなくprod外部システムを指すように変更します)。

2)buddaが言及しているように、管理者設定には機能モジュールを使用し、Nodeエクスポートモジュールをコンテンツのエクスポート/インポートにすべて削除モジュールと組み合わせて使用​​します。したがって、ワークフローは次のとおりです。

node_exportとfeaturesを使用してノード/機能をファイルにエクスポートしますオプションで(できれば)バージョン管理prodシステムにファイルをロードしますdrushまたはadminインターフェースを使用して機能をロードしますdrush delete-allまたはadminインターフェースを使用してインポートするタイプのすべてのノードを削除しますdrush ne-importまたは管理インターフェイスを使用して、エクスポートしたノードファイルからノードをインポートします。 1つの注意点として、コンテンツが一方向にのみ進む標準的なワークフローを採​​用することを強くお勧めします。 Dev-> ProdまたはProd-> Dev(私はこれが好きです)。

私はこれを実行し、いくつかの大きなシステムでこれを実行していますが、かなり良い結果が得られていますが、このAppleをスライスする方法は常に数多くあり、最適な方法を選択します。

4
coderintherye

これは受け入れられた答えのある古い質問ですが、私にはまだ別の質問の余地があると思います。

最初に、私はFeaturesはこのタスクに適したツールではないと思いますので、代替のツールセットを提案します。

チームコラボレーションの前提条件は、運用サーバーとは別のプロジェクトの開発バージョンをテストするためのステージングサーバーを用意することです。すべての開発コードはステージングサーバーでテストされ、安定していて展開の準備ができている場合にのみ運用サーバーにプッシュされます。ただし、開発者はステージングサーバーで直接作業しません。各開発者は、リビジョンコントロールとソースコード管理(SCM)を使用して自分のワークステーションで作業し、チームの他のメンバーと作業を調整します。

SCMシステムにより、チームメンバーは互いに干渉することなく、コードの異なるブランチで並行して作業できます。 masterブランチのみが、テスト目的でステージングサーバーにデプロイされます。

実稼働、ステージング、ワークステーション間でデータベースをミラーリングするために、共有ホスティングを使用していて、独自のデータベースを管理していない場合に使用できる Backup and migrate という名前のモジュールがあります。独自のデータベースサーバーを管理している場合、これはそのサーバー上の唯一のプロジェクトであり、mysqlを使用すると、次のコマンドのペアが便利です。

を投げ捨てます:

mysqldump --all-databases --opt -u root -p > DUMP.sql

復元するには:

mysql -u root -p < DUMP.sql

あなたのサーバーがそのサーバー上の唯一のデータベースではない場合、データベースのみをダンプするmysqldump(またはmysqlを使用していない場合は同等)のスクリプトを実行します。

それがマスターである実動サーバー上のデータベースであるというポリシーを作成します。ステージングサーバーとワークステーションは、運用データベースのコピーである必要があり、その逆ではありません。

Drupal 7は、すべての管理設定をデータベースに保持します。これは、本番サイト、ステージングサイト、ワークステーション間でデータベースをミラーリングすると、機能

今、コードを共有するために:

開発チームのメンバー間でコードを共有するための標準的な方法は、SCMシステムを使用することです。 Drupalはデフォルトでgitという名前のこのようなシステムで管理されます。

Gitは、ローカルまたはリモートのリポジトリの使用を許可します。チームメンバーが同じ物理スペースに配置されている場合は、ステージングサーバーにローカルリポジトリをセットアップできます。地理的に分散している場合は、リモートリポジトリを設定できます。開発中のコードで他の人が読み取りアクセスをしても構わない場合は、Drupal.orgでsandboxをリモートリポジトリとして使用できます。 GitHubでプロジェクトエリアを使用することもできます。 GitHubはリポジトリであるだけでなく、コラボレーション用のツールがいくつか付属しており、パブリックリポジトリとプライベートリポジトリの両方を使用できます。

基本的に、SCMシステムを使用すると、チームメンバーは、チームメンバーが共有するリポジトリからソースコードとドキュメントをプルし、作業が終わった後で再度プッシュすることができます。 SCMは変更を追跡し、競合がある場合(つまり、他のチームメンバーがコミットした変更を含まないコードをプッシュしようとした場合)、通知し、この競合を解決する方法を提案します。

通常、タスクがチームのメンバー間でどのように分割されるかについての誠実なコミュニケーションがあれば、衝突はありません。しかし、SCMシステムが物事を追跡しているため、ミスが発生した場合や通信が失敗した場合でも、競合は管理可能になります。

git(GIYF)の使用と使用に関するチュートリアルはたくさんあります。私がお勧めする2つは、git-scmWebサイトとPro Gitスコット・チャコンによる。

0
Free Radical