7

同じコードベースを共有するPHPWebアプリケーションの複数のインスタンスを管理するための最良の方法（または最も簡単な方法）を探しています。

あなたのためにそれを分解させてください：

私たちのドメインは、アプリケーションの複数のインスタンスをホストしており、それぞれに独自の設定ファイルとデータベースがあります。

http://mydomain.com
|
| ------ / customer1 /
|
| ------ / customer2 /
|
| ------ / customer3/+カスタム機能

顧客1と2が（私たちがホストする）アプリケーションを購入し、そのアプリケーションの基本モデルを持っているとします。（つまり、カスタマイズされていません）

ただし、顧客3は機能XまたはYを必要としているため、その機能をコーディングしてアプリケーションに追加します。

ただし、コードベースが更新されると（つまり、フレームワークのコアクラスのセキュリティ修正が行われると）、3人の顧客全員がベースコードの更新を取得する必要があります。

この種のセットアップを管理するための最良の方法は何でしょうか？FTPを使用してすべてのファイルを手動でアップロードするのは面倒であり、コードをマージすることはできません。

Gitを使用することはおそらく解決策ですが、どうすればそれを実行できますか？顧客ごとに個別のリポジトリを作成しますか？100人を超える顧客に成長した場合はどうなりますか？

このような設定を使用する必要がある理由と使用しない理由を含め、あらゆる洞察を歓迎します。（ただし、お客様のアプリケーションをホストするのは私たちになることを忘れないでください）

4

3 に答える 3

2

私はこの数年前にやったことを覚えているので、あなたは私が今これで少し錆びていることを考慮に入れなければならないでしょう。

すべてのインクルードを1つの.phpファイルに結合したスタンドアロンフレームワークを構築しました。これを使用したフレームワークはPULLリクエストを実行し、フレームワークのmd5が中央サーバーのフレームワークと一致した場合、更新は必要ありませんでした。それ以外の場合は、https経由で新しいフレームワークをダウンロードし、独自のコピーを置き換えます。これにより、それを使用する他のすべてのアプリにプルされた自動更新システムが作成されました。

これに対する主な問題は、たとえば構文エラーが発生し、それを中央サーバーにアップロードすると、他のすべてのサーバーにプルされて破損することです。cronジョブを使用して、フレームワークを使用しないプルリクエストを作成することをお勧めします。これにより、壊れたフレームワークがプルリクエストを実行してフレームワークの構文エラーを修正することができなくなります。これにより、少なくとも、中央サーバーで構文エラーを修正すると、自動的に修正する機能が追加されます。ただし、この場合、各更新をテストするためのステージングサーバーを用意することは非常に重要です。

もちろん、これは基本的なことであり、フレームワークが使用するイメージや、SQLの更新などもプルオーバーする必要があると言っているかのようです。

大量のエラーを防ぐために、中央サーバーにアップロードする前に、これを徹底的にテストする必要があります。理想的ではありません！単体テスト、ステージングサーバー、小規模で単純な更新ですが、より頻繁に（大規模な更新は失敗する可能性が高く、失敗した場合は元に戻す可能性が高くなります）、すべてリスクを軽減するのに役立ちます。

また、多くの異なるサイトで使用することを計画している場合は、フレームワークを可能な限り柔軟にするために、最初からフレームワークを非常によく構成する必要があります。最初に間違って設計した場合、将来的に再設計することはほぼ不可能になる可能性があります。たとえば、データベースアクセスにPDOを使用するのが賢明かもしれません。ただし、クラスなどがデータベースとの対話方法を知らない間（mysqlまたはoracleに関係なく）、すべてのアプリケーションが異なるデータベースを使用できるようにします。可能であれば、少なくとも1つに固執することをお勧めします。

設計的には、他の言語フレームワークを調べて、それらがどのように機能するかを確認するのが最善です。優れた設計原則に固執し、該当する場合にのみ設計パターンを使用し、MVCに注意する必要があります。

参考文献...

これは簡単な作業ではないので、注意してください。

于 2012-11-23T19:12:06.780 に答える
1

1つの質問に2つの異なるタスクを混在させました

  • 分岐コードの開発とサポート
  • （任意の）SCMからライブシステムへのコードのデプロイ

1番目の質問への回答（最新の場合）SCMはブランチとマージブランチです（各顧客には独自のブランチがあり、そこに単一の開発ブランチから必要な部分をマージします。または/better/と「branch-per-task」を使用します。必要なすべてのターゲットでタスクブランチをマージし、チェリーピッキングを回避します）

2番目の質問に対する回答は、SCMと対話できる「ビルドツール」です（詳細な回答については、後で詳細を記述する必要があります）。

于 2012-11-23T18:47:57.820 に答える
0

カスタム機能をモジュール化します。プラグインまたは拡張機能を備えたWordPress/Joomlaと同様のアーキテクチャを使用します。これにより、顧客は簡単に個別の機能セットを使用できますが、すべて同じベースコードを共有できます。

于 2012-11-23T18:45:34.360 に答える