Wir arbeiten an einer Software, die sich nun in mehrere projektspezifische Varianten entwickelt hat. Aktuell ist das gelöst, indem jede Variante als eine vollständige Kopie des Projekts modelliert ist. Das ist natürlich extrem unschön und aufgrund der wiederholten Redundanz wird die Wartbarkeit auch nicht gerade besser. Wir sind sicherlich nicht die ersten, die diesem Problem entgegenstehen - daher die Frage: Wie habt ihr das gelöst?
:
Verschoben durch Admin
Kommt auch immer auf die Möglichkeiten der Versionsverwaltung an. In git könnte man einen generischen Software-Teil als submodule referenzieren (Achtung: Submodul-Handling ist hässlich!) und projektspezifische Dateien oder Konfigurationen im jeweiligen Kundenprojekt ablegen. Wenn die Unterschiede zwischen Varianten sehr gering sind (z.B. sich nur wenige Werte unterscheiden, nicht aber Programmcode) sind zerteilte, sich referenzierende Repositories aber Overkill, dann könne schon ein zusätzliches Build-Target reichen.
Danish schrieb: > vollständige Kopie Autsch - Das wird euch in der Zukunft noch einholen... In welcher Sprache macht ihr das denn? Am besten die Software in logische Teile zerlegen und daraus jeweils unabhängige Bibliotheken machen. Für die Projekte jeweils ein eigenes Softwareprojekt erstellen und darin die Bibliotheken referenzieren. Hat den Vorteil, das spätere Bugfixes von den Bibliotheken besser verteilt werden können. Alles was nicht so gehandelt werden kann, über ein config File im projektspezifischen Projekt einstellen. Edit: Von Submodulen (git) oder Externals (subversion) rate ich auf jeden Fall ab. Das führt praktisch immer zu problemen. Sag mal deine Arbeitsumgebung (Sprache, Versionsverwaltung, Toolchain, Buidlautomatisierung falls vorhanden)
:
Bearbeitet durch User
Operator S. schrieb: > Sag mal deine Arbeitsumgebung (Sprache, Versionsverwaltung, Toolchain, > Buidlautomatisierung falls vorhanden) Matlab & Simulink. "Deployment" über Codegenerierung. Ein Build-Tool gibt es daher nicht. Das Handling von Binärdaten mit git ist auch nicht gerade ideal (Patches können nicht angewandt werden, Diffs gehen nicht, etc...). Wir arbeiten mit git.
Naja, 3 Varianten, das ist ja nix. Da gibt es ganz andere Konstellation, wo's wirklich hässlich wird. Aber 3 Varianten sind einfach: Es gibt nur ein "Projekt" bzw. Repo. Daraus werden immer die drei Varianten gebaut. Die Architektur der Software ist eben an diesen 3 Varianten ausgerichtet. Es gibt einen Kern, den alle Varianten verwenden, und den Variantenspezifischen Code. Mein (schmerzhaft) gemachte Erfahrung: Drei Kopien die sich in Details unterscheiden, sind eine Garantie für absolutes Chaos. Werdet ihr in Zukunft noch merken. Wird mit der Zeit immer schlimmer. Bis keine Wartung mehr möglich ist. Horror pur. Auch der Ansatz mit Bibliotheken etc. verkompliziert das ganze Handling nur ungemein. Unterm Strich arbeitet man dennoch nur an einem großen "Projekt" das nun über unterschiedlichen Bibliotheken und den drei Varianten verteilt ist. Eine wirkliche Unabhängigkeit existiert nicht. Die Realität sieht so aus: Bug tritt in Variante A auf. Die Wahrscheinlichkeit dass der Bug in einer Bibliothek ist, ist umso größer, je weniger sich die Varianten unterscheiden. Also wird man meistens an den gemeinsamen Bibliotheken arbeiten. Dabei hat man viel schlechtere Testmöglichkeiten, da jedes mal die geänderte Bibliothek irgendwie in die aktuelle Variante importiert werden muss, mit der man gerade arbeitet. Overhead ohne Ende. Wenn dann die Bibliothek gefixt wurde, und die aktuelle Arbeits-Variante darauf angepasst wurde, muss man die geänderte Bibliothek nun in die verbleibenden anderen Varianten integrieren. Mit den Bibliotheken gewinnt man nix, außer ein Riesenaufwand für nix. Am Ende vom Tag muss man eh immer alle drei Varianten gemeinsam bearbeiten. Von daher kann man sich diesen Aufwand sparen. Bibliotheken funktionieren witzigerweise dann am besten, wenn sich Bibliotheks-Team und Anwendungs-Team nicht kennen, geschweige denn gegenseitig beeinflussen können. Dann macht das Bibliotheks-Team was es will, und das Anwender-Team muss die Bibliothek fressen, so wie sie ist. Aber bei Varianten in einem Unternehmen existiert diese Trennung nicht. Das ist der Kern des Problems.
Danish schrieb: > Wir sind sicherlich nicht die ersten, die diesem Problem entgegenstehen > - daher die Frage: Wie habt ihr das gelöst? Kommt darauf an was für Varianten und in welcher Sprache, wie umfangreich usw. In dem Moment wo eine Kopie gezogen und getrennt weiter gecoded wird gibt es keine Varianten mehr. Das hat sich dann erledigt. Selber mache ich das per Unit(s), Das wird in im VCS als branch behandelt. Aber da geht es auch nur um unterschiedliche Geräte in C. Bei größeren Projekten kommt man um Strukturen/Mamagement in der Architektur nicht herum. Aber das ist so banal wie zu allgemein.
Ich würde auf jeden Fall die gleichen Teile in eine gemeinsam nutzbare Form bringen, am besten einen 3-way merge ueber die 3 quellstände machen Sich damit vertraut machen welche Möglichkeit zu etwas generischeren Programmierung in deiner Umgebung vorhanden ist Auch wenn es vielleicht nur wenig Code ist würde ich das so schnell wie möglich machen alles andere ist Chaosvorbereitung für die Zukunft Was ist denn der Umfang und wie viele arbeiten an dem Code
Danish schrieb: > Wir sind sicherlich nicht die ersten, die diesem Problem entgegenstehen > - daher die Frage: Wie habt ihr das gelöst? mit nem headerfile das die Variante bestimmt und if conditionen die den spezifischen abhängigen Code (oder seine Ersetzung) zur Kompilation freigibt das ist je nach Projektgrösse dann wieder variabel, manchmal sind komplette includes so ausgeklammert oder eben inkludiert... manchmal nur eine funktion oder es ändert sich nur ein Wert 'sid
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.