ZurĂŒck zum Blog

Getrennte Wege

📅  

Die Produktentwicklungsstrategie

PĂŒnktlich mit dem Installationsbeginn fĂŒr des dritte Referenzsystem konnten wir eine Lösung unseres Hauptproblems in der Strategie der Produktentwicklung lösen.

Das Problem besteht kurz zusammengefasst darin, dass es möglich sein soll Features kundenĂŒbergreifend aber auch kundenspezifisch entwickeln zu können. Ebenso mĂŒssen gewisse Konfigurationen (wie Layout, Styling, etc) kundenĂŒbergreifend durchzufĂŒhren sein, andere kundenspzifisch.

Einen Teil dieses Problems hatten wir damit gelöst, dass wir einzelne Module (in Form von Rubygems und Rails Engines ausgefĂŒhrt) erstellt haben, wie die ERP-Schnittstelle. Schon beim zweiten Referenzsystem hatten wir aber die Schwierigkeit, dass alle Gems installiert werden mĂŒssen, da des Gemfile “mitten” in der Applikation liegt und damit kundenĂŒbergreifend ist.

Wir haben die Steuerung zunĂ€chst ĂŒber Rails Environments zu trennen versucht, aber auch dabei mĂŒssen in allen Systemen alle Gems installiert werden. Das Thema unterschiedlichen Layouts (CSS Files, DRYML Tags) hatten wir ĂŒberhaupt noch ignoriert.

Wir haben auch versucht, möglichst viele Einstellungen in die Datenbank zu verlegen. Bei den oben genannten Beispielen ist dies aber nicht möglich. Wir haben damit nur bei etwa 10 Dateien ein Problem, diese bei jedem Update manuell systemspezifisch einzuspielen, ist aber einfach zu viel Aufwand und zu fehleranfÀllig.

Doch dann kam die Erleuchtung in Form von Symlinks und systemspezifischen Code-Repositiories. Das bedarf einer ErklÀrung, da der Ansatz eigentlich sehr einfach, aber nicht verbreitet ist. Die genannten 5-10 Dateien, werden in der Applikation durch symbolische Link auf Dateien innerhalb eines kunden- oder systemspezifischen Verzeichnisses (/vendor/customer) ersetzt.

Dieses Verzeichnis ist in einem getrennten Code-Repository. Damit reduziert das Deployment, das wir ohnehin per Git durchfĂŒhren auf einen zweiten Pull-Vorgang, der auch per Script automatisiert werden könnte.

Auf Entwicklungsrechnern kann damit sogar rasch zwischen mehreren Systemen durch eine weitere Indirektion gewechselt werden: Pro System gibt es ein Verzeichnis innerhalb von /vendor/customers


Indirektion


Im Zuge dessen haben wir die Repositories fĂŒr alle 6 Systeme (3 Referenzsysteme mit je einem Entwicklungs- und einem Stagingsystem) angelegt und tranportiert.

Wir haben das System nun auf allen Rechnern und Servern getestet, es funktioniert problemlos.

Damit können wir weitere Modularisierungen, wie etwa die Umwandlung der eigentlichen Applikation in eine Engine auf einen wesentlich spÀteren Zeitpunkt verschieben evtl sogar ganz absagen.

Vermischtes

FĂŒr das erste Referenzsystem wurden einige Arbeiten durchgefĂŒhrt:

ZurĂŒck zum Blog