22

あるクライアントが、あるニッチで成功した Rails アプリを別の同様のニッチに適用したいと考えています。アプリのこの新しいインスタンスは、非常によく似たものから始まります。機能はすべて同じで、ロゴと色が異なります。ただし、新しいサイトが成功した場合、必然的に、元のサイトには適用されない大幅なカスタマイズが必要になります。同時に、バグが修正され、1 つのアプリに改善が加えられた場合、両方のアプリがそれらの改善を共有できるはずです。

この問題に対処するための戦略やリソースを提案できる人はいますか? 両方のアプリに適用される変更のテストと実装に大幅に時間がかからないようにするにはどうすればよいですか?

はい、その答えには SCM、プラグイン、gem、Rails エンジンが関係していることはわかっています。これらのツールは今後も使用されます。しかし、この問題を解決するためにこれらのツールをいつ、どのように使用するかを知りたい.

リンクも大歓迎です。

この質問は次の質問と同じではありません。

同じコードベースで複数の Web サイトを実行していますか? 私の質問では、まったく同じアプリを異なる設定で実行していません。

複数のコードベース間で変更をどのように同期しますか? 同様の質問をしていますが、具体的には Rails アプリについて質問しています。

4

4 に答える 4

32

私たちは現在、あなたが説明しているものと非常によく似たセットアップで作業しています。

クライアント向けにやや大きな Rails アプリ (販売、在庫管理、製品カタログなど) の開発を開始しました。それを終えた後、ほぼ同じ機能に対するいくつかの新しい要求がありました.

ただし、元のアプリは維持され続け、新しい機能を追加し、バグを修正する必要がありました。

拡張されたものは、ほとんどの機能を維持するために必要でしたが、外観と外観を変更しました。

私たちが行ったことは、一連の手順に従うことでした。

  1. まず、コードのクリーンアップ、テーブルへのハードコード参照のプル、クエリの削減と最適化、不足しているインデックスの検索、および ActiveRecord の使用を改善する方法を開始しました。
  2. ある程度満足した後、不足しているテストの開発を開始しました。いくつかのアプリで同じコードベースを維持し、コア機能を新しい変更から可能な限り保護する必要があるため、なぜそれが有用なのかを十分に強調することはできません.
  3. それは魔法の言葉でもありました: コア機能。再利用できる基本機能の選択と、すべての汎用コードの抽出を開始しました。これにより、コントローラー、モデル、ビューが混在し、モジュール、プラグイン、gem に変更し始めました。何がどこに行くの？コードに大きく依存します。経験則として、ドメイン言語を扱わない機能はプラグイン (Rails にあまり依存しない場合は gem) に移動します。
    1. このアプローチにより、いくつかのプラグイン、gem を導き出し、それらをまとめて元のプロジェクトを再構築し、独自の GIT リポジトリにたどり着きました。このようにして、すべてのコンポーネントとそれぞれの他のいくつかの GIT リポジトリを接着するメインの「テンプレート」リポジトリができました。
    2. 最後に、簡単なテーマ システムを開発します (基本的には /stylesheets/themes/:theme_name/ を読み込み、DB から theme_name を取得します)。これはイントラネット プロジェクトであるため、適切な CSS スタイリングがあればほとんど何でもできます。IE で作業するには、より複雑なアプローチが必要になると思います。
    3. 次に、そのメイン リポジトリを使用して、その上に新しい機能を開発しました。

さて、コアベースへの変更をどのように処理しますか。テンプレートリポジトリから始めます。修正または変更が必要な場所を修正または定義し、その場所または対応する gem/plugin で変更します。適切にテストした後、GitHub アカウントにデプロイします。

最後に、そのテンプレート リポジトリから他のプロジェクトをマージ/リベースし、新しい更新を取得します。

少し複雑に聞こえますが、セットアップのみでした。現在のワークフローは非常にシンプルで簡単で、複数の開発者と大きな問題なく作業できる利点があります。

于 2009-11-21T03:26:23.950 に答える
3

メイン サイトへの最小限の操作で、テンプレートを拡張してスタイルを変更しながら、そこから Ruby コードを使用できる可能性があります。私は Django で広範囲に取り組んできましたが、レイアウトは次のようになります。

project/
    sites/
        site_one/
            templates/
            models.py
            settings.py
            urls.py
            views.py
        site_two/
            templates/
            models.py
            settings.py
            urls.py
            views.py
    base_app/
    settings.py

Railsで同様のことを試すことができます：

main_webapp/
    app/
    config/
    ...
    sites/
        site_one/
            controllers/
            models/
            views/
        site_two/
            controllers/
            models/
            views/

機能はサイト間で同一であるが、レイアウトとスタイルが異なるだけであると仮定すると、モデルとコントローラーのコードはまったくないか、ほとんどありません。特定のサイトにさらに機能を追加したい場合は、目的のサイト フォルダーの下にコードを貼り付けてください。

Django には、サイトの概念と、1 つの特定のプロジェクト フォルダーとアプリ フォルダーでテンプレートを検索する機能もあります。これらの機能をコピーして Rails に持ち込んで、1 つのコードベースから複数のサイトを実行することができます。

Rails ソリューションを探していることは承知していますが、Django での方法をチェックアウトし、便利な機能の一部を別の側にコピーすることもできます。Rails 固有の機能が気に入ったら、Django/Python に移植します。

于 2009-12-01T16:38:56.140 に答える
1

私の会社でも似たようなことをしています。現在複数の環境（本番、テスト、開発）が関係していることを除いて。私たちはSVNをSCMとして使用してコードをまっすぐに保ち、現在の安定した環境を複製してアプリケーションの別のバージョンを作成できるようにしています(ロゴや特定の機能などを変更する可能性があります)。Apache/Nginx とPhusion's Passengerで環境を実行することを強くお勧めします. これにより、同じ/類似のコードベースで、これらすべてのアプリケーションを個別に実行できます。以上です。ライブ データを分離しておくために、1 つの運用と 1 つの開発の DB が必要ですが、この方法で 2 つのアプリ インスタンスを同じデータベースに簡単に接続できます。これまでのところ、プライマリ本番サーバーをダウンさせることなく、複数の Web アプリケーションを開発、テスト、デプロイできるという点で、非常にうまく機能しています。

于 2009-11-20T18:40:51.643 に答える