Vorschlag für ein Verzweigungsmodell für dasselbe Projekt mit mehreren Clients

Wir haben ein sehr großes Projekt, das mehrere Anwendungen umfasst, die als Basis für verschiedene Kunden dienen.

Jeder Kunde hat seine eigene Personalisierung des Produkts, unterschiedliche Meilensteine, unterschiedliche Anforderungen usw., und daher wird sich jedes Projekt unabhängig von seinen eigenen Anforderungen weiterentwickeln.

Der Kern des Projekts ist in jedem Projekt ähnlich (aber nicht gleich) und die Organisation ist so aufgebaut, dass es Teams gibt, die jeden Kunden unabhängig behandeln (aber bei Bedarf mit ihnen kommunizieren). Bisher konnte ich kein Schema finden, das unseren Anforderungen entspricht, weder durch Durchsuchen des Internets noch durch eine brillante Idee :)

Bisher haben wir daran gearbeitet, das Produkt für alle Anforderungen geeignet zu machen, mit spezifischen Zweigen für notwendige Änderungen, aber obwohl das Produkt eine gute Architektur hat, wird es langsam zu einem großen Problem. Hier sind die Hauptprobleme, mit denen wir konfrontiert sind:

• Unterschiedliche Meilensteine ​​für jeden Kunden: Das bedeutet, dass jedes Team Versionen zu unterschiedlichen Zeiten erstellen muss, ohne dass der Rest der Verpflichtungen die Stabilität oder das Produkt beeinträchtigt.
• Unterschiedliche Anforderungen, die sich in einigen Fällen auf den Kern des Systems auswirken können oder nicht.
• Große Teams (20+ Teammitglieder)
• Umgang mit Fehlern im System: Was tun Sie, wenn ein Team in seinem Projekt einen Fehler findet, der andere Kunden betreffen könnte?

Hinweis: Es handelt sich um ein Projekt mit 10 + M LOC.

Hinweis: Wir verwenden Team Foundation System, Visual Studio 2008 und C # (hauptsächlich).

Irgendwelche Vorschläge, Quellen oder Ideen, wie man die Situation angeht? Gibt es ein Modell auf dem Markt, das ein ähnliches Problem hat?

Eigentlich würde ich vorschlagen, dass Sie kein Verzweigungsmodell benötigen, sondern einen umfassenden Ansatz, um die mehrdimensionalen Einschränkungen in Bezug auf das System ohne Verzweigung zu bewältigen . In der Praxis glaube ich, dass es immer ein Problem sein wird, mehrere Systeme zu warten, die einige Gemeinsamkeiten aufweisen, sich jedoch in Zweigen unterschiedlich entwickeln. Daher ist es besser, alles in ein einziges System zu verwandeln, das sich als Ganzes entwickelt, aber aus unterschiedlichen Konfigurationen besteht. Dies mag zu simpel erscheinen, aber es gibt umfangreiche Forschung auf diesem Gebiet mit vielen erfolgreichen industriellen Anwendungen.

Der Name für diesen Ansatz lautet Software Product Lines oder manchmal Product Line Engineering . Auf der Seite Software Product Lines von CMU SEI :

Eine Software-Produktlinie (SPL) ist eine Reihe von softwareintensiven Systemen, die eine gemeinsame, verwaltete Reihe von Funktionen gemeinsam haben, die den spezifischen Anforderungen eines bestimmten Marktsegments oder einer bestimmten Mission entsprechen, und die auf vorgeschriebene Weise aus einer gemeinsamen Reihe von Kernressourcen entwickelt werden .

Die Schlüsselidee ist, dass jede Anforderung, jeder Meilenstein, jede Funktion (ein Schlüsselbegriff in dieser Domäne) Teil des Gesamtsystems auf höchster Ebene ist. Die tatsächlichen Systeme, die bei verschiedenen Kunden bereitgestellt werden, sind im Wesentlichen eine Sammlung von Funktionen. Jedes Feature ist jedoch nicht nur eine physische Komponente, die in das System integriert ist, sondern wird als abhängig von oder aktiviert durch andere Features definiert (sodass Sie durch Auswahl eines Features dessen Abhängigkeiten usw. automatisch einbeziehen können).

Anstatt dann alle diese Zweige zu verwalten, warten Sie am Ende ein System zusammen mit einer Reihe von kundenspezifischen Konfigurationen.

In der Praxis mag es schwierig oder sogar unmöglich sein, mit einem sehr großen System auf einen solchen Ansatz zu migrieren, aber selbst dann wird es nützlich sein, die in SPL verwendeten Ansätze zu untersuchen, um zu bewerten, welche dort verwendeten Ansätze zumindest (teilweise) sein können. in Ihre Arbeit integriert.

Einige zusätzliche nützliche Links:

• Wikipedia: Produktlinienentwicklung
• Fallstudien von CMU SEI
• Software Product Lines , eine Website mit viel Einführungsmaterial.

Als ich bei meinem ersten Job anfing, arbeitete ich an ähnlichen Projekten (aber in kleinerem Maßstab) und wir hatten die gleichen Probleme. Wir haben auch mit allgemeinen Anforderungen an das Lösungshandling für alle Kunden begonnen, aber dies war nur bis zu dem Punkt möglich, an dem die Anforderungen widersprüchlich werden. Wir haben das getan, was Sie vorgeschlagen haben, und für jeden Kunden eine eigene Version gestartet. Selbst dies löste das Problem mit den Anforderungen und der Anpassung. Es wird zu einem Alptraum für die Wartung, um Fehler und globale Änderungen zu beheben.

Da der Code in der Anwendung nur ähnlich war, war das Zusammenführen von Änderungen von einer Kundenversion zu einer anderen sehr komplex und es musste jede Version einzeln erneut getestet werden (wir hatten keine automatischen Tests!). Es verursachte häufig Regressionsfehler in verschiedenen Versionen. In Ihrem Szenario kann dies sogar noch schlimmer sein, da ein Team den Fehler in seiner Version beheben wird und ein anderes Team diese Änderung von der Version, die sie nicht vollständig verstehen, zusammenführen muss (wir waren ein Team, das an allen Versionen gearbeitet hat).

Wenn Sie keinen gemeinsamen globalen Kern haben, treten dieselben Probleme auf. Bevor ich das Unternehmen verließ, stellten wir fest, dass unser Ansatz falsch war. Um ein solches Entwicklungsszenario zu unterstützen, benötigten wir ein gemeinsames erweiterbares Kern- und Datenmodell, das über die oberen anpassbaren Anwendungsebenen konfiguriert werden kann. Dieser Kern sollte als Basis für jede kundenspezifische Anpassung verwendet und von einem separaten Team verwaltet werden. Dies wird einige Verwaltungskomplikationen mit sich bringen, da mehrere Projektmanager Ressourcen vom selben Team benötigen. Dies ist jedoch die einzige Möglichkeit, die Architektur konsistent zu machen, den gesamten Prozess zu steuern und die Versionen synchron zu halten.

Ich mag eine Art Basis sein, aber ich denke, dass das, was Sie mit Ihrem Kern Ihres Systems konfrontiert sind, das gleiche Problem ist, mit dem jeder konfrontiert ist, der Komponenten verwendet und verschiedene Versionen seiner Software warten und unterstützen muss, und diese unterschiedlichen Versionen erfordern jeweils einen anderen Satz von Komponentenversionen.

Beispielsweise

• Release 1.0 erfordert Bibliothek A 1.0, Bibliothek B 2.0, Bibliothek C 5.6
• Release 2.0 erfordert Bibliothek A 1.0, Bibliothek B 3.7, Bibliothek C 5.7
• Release 3.0 erfordert Bibliothek A 1.2, Bibliothek B 3.7, Bibliothek C 5.8

Die Art und Weise, wie wir das Komponentenproblem gelöst haben, besteht darin, alle Versionen der Bibliotheken in unserem Versionskontrollsystem zu haben (wir bauen sie auf der Quelle auf) und jedes Projekt die richtige Bibliotheksversion verwenden zu lassen, indem der Suchpfad geändert wird (Referenzpfad?).

In Delphi ist dies einfach über die Konfigurationsdatei des Projekts (unter Quellcodeverwaltung) möglich, wenn Sie die Bibliotheken zur Entwurfszeit nicht benötigen. Andernfalls ist dies weiterhin möglich, wird jedoch etwas schwieriger, da Sie die zu verwendende Delphi-IDE wechseln müssen Auch die richtige Version (Registrierungsdateien (.reg) unter Versionskontrolle können hier Abhilfe schaffen).

Eine Lösung für Ihr Kernsystem könnte darin bestehen, es als Bibliothek zu behandeln, für die Sie verschiedene Versionen verwalten. Dies bedeutet im Wesentlichen, dass Sie für jede Version unterschiedliche Zweige einrichten müssen. Die Anwendung eines Clients kann dann die richtige "Version" Ihres Kernsystems verwenden, indem sie auf den Zweigordner des richtigen Kernsystems verweist.

Wenn die Abhängigkeiten für Ihr Kernsystem dann dem obigen Beispiel ähneln würden, haben die Abhängigkeiten für Ihre Clientanwendungen "nur" eine zusätzliche Referenz: die Version Ihres Kernsystems.

Ein zusätzlicher Vorteil bei Anwendungen mit mehreren Clients besteht darin, dass Sie auswählen können, wann eine bestimmte Version Ihres Kernsystems verwendet werden soll, und dass Sie nicht von Änderungen am Kernsystem betroffen sind, die Sie noch nicht für eine bestimmte Clientanwendung verwenden können.