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


12

Drupalサイトで別の開発者と仕事をしています。私たちは、お互いに邪魔されることなく、サイトのさまざまな部分で同時に作業する良い方法を見つけるのに苦労しました。私たちはサイトの同じ開発インスタンスで作業を試みましたが、多くの場合、お互いにつま先を踏んだり、悪いコードでサイトを停止したりして、解決されるまで他の人が作業を続けることを不可能にしました。そのため、個別の開発インスタンスに移動しました。しかし、今では、作業をサイトの単一のインスタンスにマージするのは大きな苦痛です。基本的に、共有コピーのすべてをやり直すことになります。

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

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

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

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

  • または、同じサイトのコピーに取り組んでいますか?(そうしないでください)


編集:コメントでは、Featuresでエクスポートできないものについて説明しましたが、その1つが分類法でした。それに対処する別の質問があります。


私は興味があります、あなたは機能を通して具体的に何ができませんか?より良い質問は、データベースのマージルートをたどるのではなく、機能を使用して、または使用せずに、これらのものをコードにエクスポートする方法を尋ねることです。
解読

@Decipherフラグ、分類、メニュー、ブロック、および実際のコンテンツを考えることができます(そうするモジュールは他にもあると思いますが)。その後、機能をサポートしない新しいモジュールを使用するたびに、最初にサポートを追加する必要があります。それをする時間がありません。
Chaulky

Drupalconで「機能」スプリントを実行して、不足しているものの一部にサポートを追加する必要があると思います。
coderintherye

1
@Decipher OK、コードにすべてのブロックを保存する方法があることに同意します。しかし、まだ使用していない、使用したいすべてのモジュールに機能サポートを追加する必要があるのは不合理だと思います。
ショーキー

1
私はそれを提案したことはありません、あなたが提案したモジュールの機能サポートが既にあることを単に提案しています(Strongarm経由でFlagがエクスポート可能であると仮定して)。私はあなたをこの道に追いやろうとはしていません。それは、データベースの道よりもチームでコードベースのアプローチを維持するのが簡単な、より困難な道をたどる代わりにすぎません。私のチームでは、できる限り機能/コード以外のアプローチを強く思いとどまらせます。FeatureがDrupalの中核部分になるまで機能を実現できないものがたくさんあることは承知していますが、多くのことができます。
解読

回答:


5

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

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

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


4

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

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

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

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

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

私はこれを行っており、いくつかの大きなシステムでこれを行っていますが、かなり良い結果が得られていますが、このリンゴをスライスする方法は常にたくさんあります。


0

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

まず、Featuresはこのタスクに適したツールではないと思い、代替ツールセットを提案することを前もって申し上げます。

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

SCMシステムを使用すると、チームメンバーは互いに干渉することなく、コードの異なるブランチで並行して作業できます。テストのために、マスターブランチのみがステージングサーバーに展開されます。

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

を投げ捨てます:

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

復元するには:

mysql -u root -p < DUMP.sql

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

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

Drupal 7はすべての管理設定をデータベースに保持していることに注意してください。つまり、運用サイト、ステージングサイト、およびワークステーション間でデータベースをミラーリングすると、機能なしでadmim設定が移行されます

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

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

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

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

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

git(GIYF)の使用を開始して使用するためのチュートリアルがたくさんあります。git-scmの WebサイトとScott ChaconのPro Gitの 2つをお勧めします。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.