Führen Sie eine angepasste Version von einer Rails-Anwendung

Question

unsere grundlegenden Anforderungen hier:

• Wir haben eine Basis Rails-Anwendung haben, die aktiv gepflegt wird.
• Wir möchten eine angepasste Version dieser App anbieten, vorausgesetzt, dass:
  • Server müssen in unserem Kundenstandort wohnen und auf einer anderen Domäne ausgeführt werden.
  • Es gibt eine spezifische Protokollierungsinstrumentation für ihre eigene Überwachung im Rechenzentrum.

Um dies zu tun, ich mehrere Möglichkeiten, dieses Ziel zu erreichen, sehen kann:

• Git-Zweigs
• Rails::Engine
• Rails::Application

Die naheliegendste Antwort wäre Git-Zweig sein, für volle Flexibilität.

Aber ich bin mir nicht sicher, ob es eine gute Idee ist, weil die Code-Basis weitgehend geteilt wird und die Mainline viel mehr Aktivitäten hat - das Aufholen von Rebase/Merge könnte nur ein zusätzlicher Aufwand sein.

Wir möchten die ursprüngliche und die angepasste Version so weit wie möglich entkoppeln. Mit anderen Worten, wir möchten so selten Konflikte wie möglich zwischen dem Original und dem Individuellen haben.

Rails::Engine oder Rails::Application schienen wie eine enge Idee (ich bin nicht vertraut mit Rails Engines), aber ich verstehe nicht, wie OurApp::Application und OurCustomizedApp::Application an einem Ort haben und zwischen ihnen global und dynamisch wechseln.

Wahrscheinlich wäre es schön zu haben:

• individuelle initializers, Controller und Ansichten in einem separaten Verzeichnis außer Kraft zu setzen (oder Patch) die ursprüngliche
• Fähigkeit zu spezifizieren, die app (das Original oder die kundenspezifische config/database.yml zu sein config/customer1/database.yml
• Fähigkeit zu verwenden, um die gleichen deploy.rb für Capistrano (p:) durch eine Umgebungsvariable wie RAILS_APP
• separate Konfigurationsdateien, wie so zu booten robably mit config/servers.yml und config/customer1/servers.yml zu Rollen und IPs zu definieren?)

Gibt es Praktiken/Konventionen für unsere Anforderungen? Irgendein Rat?

Unsere Apps laufen auf Ruby 1.9.2 + Rails 3.0.3.

UPDATE

Wir begannen es als Zweig Git. Wir haben eine Rake-Aufgabe erstellt, um eine Datei unter config/branch zu generieren, die Text wie "master" oder "customized" enthält, und application.rb liest sie beim Bootstrap.Configs wie database.yml oder servers.yml leben jetzt in config/mainline/ oder config/customized/, und application.rb behandelt sie entsprechend.

config.paths.config.database = "config/#{branch}/database.yml" 

Nicht perfekt, aber gut genug für jetzt. Ich werde aktualisieren, wenn wir einen besseren Weg finden, dies zu tun.

Answer 1

Ich weiß, es ist nicht die genaue Antwort, die Sie suchen, aber ich glaube, Git wird die geringste Menge an Arbeit sein - und die am einfachsten zu verwalten, langfristig - über die Anpassung der App und Hinzufügen von Logik, um die Handhabung zusätzliche Konfigurationsdateien, Änderung der Deploy-Dateien und Verwaltung der (möglicherweise) neuen CSS/JS/Template-Dateien.

Verwendung von Rebase & Merge werden viel weniger fehleranfällig sein, und solange Sie Ihre Filialen regelmäßig synchronisiert halten, sollten Sie keine ernsthaften Probleme haben, sie beide auf dem neuesten Stand zu halten. Schließlich ist Git gut darin! ;)

Answer 2

Wir benutzen Git, um das ziemlich oft zu machen.

Answer 3

Ich denke, der beste Ansatz ist, dies auf altmodische Weise zu tun.

Fügen Sie Ihrem Projekt zunächst eine Singleton-Klasse hinzu (in /lib), die etwa Affiliate heißt. Diese Klasse sollte Standardimplementierungen (was auch immer Ihre Basisanwendung verwenden soll) für alle Teile der Anwendung bereitstellen, die angepasst werden können. An dieser Stelle funktioniert Ihre Anwendung gleich, verfügt jedoch über Hooks zur Anpassung.

Am Standort Ihres Kunden, implementieren die gleichen Quellcode (als Edelstein geliefert, vielleicht?), Aber auch eine Rails-Plugin bereitstellen, die Affiliate so seine Singleton instance Methode überschreibt eine benutzerdefinierte Unterklasse zurückgibt, die kundenspezifische Informationen oder Verhaltensweisen liefert .

Bearbeitet, um hinzuzufügen: Das Risiko bei diesem Ansatz ist, dass Entwickler versehentlich Dinge brechen, weil sie nur ihre Änderungen gegen die Standard-Partner testen. Sie sollten automatisiertes Testen und kontinuierliche Integration verwenden, um dies zu erfassen.

Answer 4

Anscheinend haben Sie hier zwei interessante Anforderungen. Sie fragen, wie Sie zwei separate Anwendungen haben und dynamisch zwischen ihnen wechseln können. Ich gehe davon aus, dass Sie verschiedene 'Versionen' der gleichen Anwendung gemeinsam hosten und die App auf verschiedene Anpassungen basierend auf der Domäne wechseln lassen möchten. Dies unterscheidet sich jedoch sehr von der Verwendung von Git-Zweigen, um zwei verschiedene Anwendungen zu implementieren.

Können Sie hier Ihre Anforderungen klären?

Ich würde nicht Git-Niederlassungen als eine Lösung hier empfehlen. Ich würde empfehlen, Motoren zu verwenden. Vor allem Bündelung Ihres Motors zu einem Juwel.

Fügen Sie den Edelstein in Ihr benutzerdefiniertes Projekt ein und verwenden Sie dann die herkömmlichen Methoden zum Überschreiben der Funktionalität in einer Engine. Sie können auch die herkömmlichen Methoden zum Erweitern von vorhandenem Ruby-Code verwenden, um die Funktionalität in Ihrem Schmuckstück zu überschreiben.

Auf diese Weise behalten Sie alle Unterschiede in einem separaten Projekt. Dieses separate Projekt wird auch eigene Tests haben, etc.