Hier sind unsere grundlegenden Anforderungen:
Dafür kann ich mehrere Optionen sehen, um dieses Ziel zu erreichen:
Rails::Engine Rails::Application Die offensichtlichste Antwort wäre Git-Zweig, für volle Flexibilität.
Allerdings bin ich mir nicht sicher, ob das eine gute Idee ist, weil die Codebasis weitgehend geteilt ist 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 wie möglich Konflikte zwischen dem Original und dem Individuellen haben.
Rails::Engine oder Rails::Application schien mir eine gute Idee zu sein (Rails Engines kenne ich nicht), aber ich verstehe nicht, wie man OurApp::Application und OurCustomizedApp::Application an einer Stelle hat und global zwischen ihnen wechseln kann und dynamisch.
Wahrscheinlich wäre es schön zu haben:
RAILS_APP gestartet werden soll
config/database.yml ist config/customer1/database.yml
deploy.rb für capistrano zu verwenden (wahrscheinlich mit config/servers.yml und config/customer1/servers.yml , um Rollen und IPs zu definieren?) Gibt es Praktiken / Konventionen für unsere Anforderungen? Irgendwelche Tipps?
Unsere Apps laufen auf Ruby 1.9.2 + Rails 3.0.3.
AKTUALISIEREN
Wir haben es als Git-Zweig begonnen. Wir haben eine Rake-Aufgabe erstellt, um eine Datei in config/branch zu erstellen, 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.
Nicht perfekt, aber gut genug für jetzt. Ich werde aktualisieren, wenn wir einen besseren Weg finden, dies zu tun.
Ich weiß, dass es nicht die genaue Antwort ist, die Sie suchen, aber ich glaube, Git wird die geringste Menge an Arbeit - und die am einfachsten zu verwalten, langfristig - über die Anpassung der App und Hinzufügen von Logik, um die zusätzlichen zu behandeln Konfigurationsdateien, Ändern der Deploy-Dateien und Verwalten der (möglicherweise) neuen CSS / JS / Template-Dateien.
Verwenden von Rebase & amp; Zusammenführen wird viel weniger fehleranfällig, 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! ;)
Ich denke, der beste Weg ist, dies auf altmodische Weise zu tun.
Fügen Sie Ihrem Projekt zuerst eine Singleton-Klasse hinzu (in /lib ), die etwas wie 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 Haken, um Anpassungen zu ermöglichen.
Stellen Sie auf der Website Ihres Kunden denselben Quellcode bereit (möglicherweise als Schmuckstück geliefert), stellen Sie jedoch ein Rails-Plug-in bereit, das Affiliate überschreibt, sodass die Singleton instance -Methode eine benutzerdefinierte Unterklasse zurückgibt, die kundenspezifisch ist Informationen oder Verhaltensweisen.
Bearbeitet, um hinzuzufügen: Das Risiko bei diesem Ansatz besteht darin, dass Entwickler versehentlich Dinge kaputt machen, weil sie ihre Änderungen nur gegen den Standard-Affiliate testen. Sie sollten automatisiertes Testen und kontinuierliche Integration verwenden, um dies zu erfassen.
Anscheinend haben Sie hier zwei interessante Voraussetzungen. 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 Git-Filialen hier nicht als Lösung empfehlen. Ich würde empfehlen, Motoren zu verwenden. Vor allem Bündelung Ihres Motors in ein 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, usw.
Tags und Links ruby-on-rails-3 ruby-on-rails