web-dev-qa-db-ja.com

複数のインストールでカスタムモジュールを管理する

複数のサイトで使用されるいくつかのカスタムモジュールがあります。それらはクライアント固有であるなどの理由から、寄稿モジュールとしてリリースすることはできません。寄稿モジュールでは機能しないことを想定しています。

これに対処する次の可能性について知っています。

  • それらをコピーして貼り付けます。すべてのインストールでモジュールを最新の状態に保つことが明らかに困難になります。

  • 単一のマルチサイトインストールがあるが、これが常に可能であるとは限らない。

  • Gitサブモジュールを使用しますが、厄介な場合があります。更新を忘れることが多く、常にサポートされているわけではありません(例:Pantheon)

  • Drushは、共通のgitリポジトリからチェックアウトするスクリプトを作成します。このため、AFAIKはサイト全体に対してDrush Makeを使用する必要があり、現在は使用していません。

  • http://drupal.org/project/fserver 。私はまだそれを試していません、それが十分に安定しているかどうか誰かが知っていますか?プロジェクトの説明はあまり有望に聞こえず、7.xバージョンはありません。

他に何か/良いですか?あなたは何が好きで、なぜですか?

19
Berdir

Drush makeアプローチは、すでに述べたように、私のチームが使用しているバージョンです。

現在、drush makeをサイトで使用していない場合でも、drushによって drush make-generate が提供されるため、必要に応じて、このワークフローに移動するのは比較的簡単です。既存のサイト。したがって、新しいサイトにとってそれだけの価値があると感じる必要はありません。 :)

10
Letharion

すべてのサイトが同じサーバー上にある場合、symlinkを使用してモジュールを中央の場所からロードできます。複数のサーバーを扱う場合はrsyncを使用できます。

これでファイルの配布の問題は解決しますが、それでもアップグレードを起動する必要があります。 drushを使用すると、すべてのサイトのアップグレードを1つずつ呼び出す単純なスクリプトとともに自動化できます。

1
Máté Gelei

あなたはほとんどすべての解決策にかなり似ているようです。私がそれを読んだとき、最初に頭に浮かぶのはrsyncsymlinkのような他の2つの解決策ですが、ここでも維持するのは快適ではありません。

次に、そのモジュールについて覚えています Git Deploy これは、実際にはgitサブモジュールとの素晴らしいコンボです。

私はまだこのアイデアを試していませんが、うまくいくか、少なくともあなた自身のシステムを作るためにそれをハッキングする方法の手掛かりを与えるでしょう。

0
yvan

すべてのコントリビュート/カスタムモジュールに個別のgitリポジトリを使用します。コントリビュートまたはカスタムモジュールはそれぞれ、(サブモジュールではなく)個別のブランチにあります。

ここにgitマージの仕組みがあります:

主人

      <-- custom
        <-- custom module 1
        <-- custom module 2    

      <-- contrib
        <-- contrib module 1
        <-- contrib module 2     

マスター->リリース

ブランチを更新するbash/drushスクリプト

0
Refineo

カスタム開発したモジュールを保存するためにGitの代わりにSVNを使用しています。 localhostから変更をコミットした後、事前定義されたサーバーの場所で「svn update」コマンドを実行するbashスクリプトを実行するだけです。モジュールを新しい場所にデプロイするたびに、bashスクリプトを更新します。それは本当にシンプルなセットアップであり、面倒なしで動作します。

0