Pflegen Sie Hunderte von benutzerdefinierten Filialen über die Hauptfiliale

Derzeit haben wir einen Hauptzweig für unsere PHP-Anwendung in einem gemeinsam genutzten Repository. Wir haben mehr als 500 Kunden, die Abonnenten unserer Software sind, von denen die meisten Anpassungen für verschiedene Zwecke vornehmen, jeweils in einer eigenen Niederlassung. Die Anpassung kann ein anderer Textfeldname, eine völlig neue Funktion oder ein neues Modul oder neue Tabellen / Spalten in der Datenbank sein.

Die Herausforderung, der wir uns gegenübersehen, besteht darin, dass wir, während wir diese Hunderte von benutzerdefinierten Zweigen warten und an Kunden verteilen, von Zeit zu Zeit neue Funktionen bereitstellen und unseren Hauptzweig aktualisieren und Änderungen am Hauptzweig an den benutzerdefinierten Zweigen vornehmen möchten, um diese zu aktualisieren sie auf die neueste Version.

Leider führt dies häufig zu vielen Konflikten im benutzerdefinierten Code, und wir verbringen viele Stunden damit, jeden einzelnen Zweig durchzugehen, um alle Konflikte zu lösen. Dies ist sehr ineffizient, und wir haben festgestellt, dass Fehler bei der Lösung dieser Konflikte keine Seltenheit sind.

Ich bin auf der Suche nach einer effizienteren Möglichkeit, unsere Client-Release-Zweige mit dem Master-Zweig auf dem neuesten Stand zu halten, was zu weniger Aufwand beim Zusammenführen führt.

Sie missbrauchen völlig Zweige! Sie sollten die Anpassung durch Flexibilität in Ihrer Anwendung und nicht durch Flexibilität in Ihrer Versionskontrolle (die, wie Sie festgestellt haben, nicht für diese Art der Verwendung vorgesehen / ausgelegt ist) ermöglichen.

Beispielsweise können Sie Textfeldbeschriftungen aus einer Textdatei erstellen und nicht in Ihre Anwendung einprogrammieren (so funktioniert die Internationalisierung). Wenn einige Kunden unterschiedliche Funktionen haben, gestalten Sie Ihre Anwendung modular , wobei strenge interne Grenzen durch strenge und stabile APIs festgelegt werden, damit die Funktionen nach Bedarf hinzugefügt werden können.

Die Kerninfrastruktur und alle gemeinsam genutzten Funktionen müssen dann nur einmal gespeichert, gewartet und getestet werden .

Das hättest du von Anfang an tun sollen. Wenn Sie bereits über fünfhundert Produktvarianten (!) Verfügen, ist die Behebung dieses Problems eine große Aufgabe… aber nicht mehr als die laufende Wartung.

500 Kunden zu haben, ist ein nettes Problem. Wenn Sie sich die Zeit genommen hätten, um dieses Problem mit Filialen zu umgehen, hätten Sie möglicherweise nie lange genug handeln können, um Kunden zu gewinnen.

Erstens hoffe ich, dass Sie Ihren Kunden genügend Gebühren in Rechnung stellen, um ALLE Kosten für die Wartung ihrer benutzerdefinierten Versionen zu decken . Ich gehe davon aus, dass Kunden neue Versionen erwarten, ohne dafür bezahlen zu müssen, dass ihre Anpassungen erneut vorgenommen werden. Ich würde damit beginnen, alle Dateien zu finden, die in 95% Ihrer Filialen gleich sind. Diese 95% sind der stabile Teil Ihrer Anwendung.

Suchen Sie dann alle Dateien, bei denen sich zwischen den Zweigen nur wenige Zeilen unterscheiden. Versuchen Sie, ein Konfigurationssystem einzuführen, damit diese Unterschiede beseitigt werden können. Anstatt beispielsweise Hunderte von Dateien mit unterschiedlichen Textfeldbezeichnungen zu haben, haben Sie eine Konfigurationsdatei, die jede Textbezeichnung überschreiben kann. (Dies muss nicht auf einmal erfolgen, sondern es muss nur eine Textfeldbezeichnung konfiguriert werden, wenn ein Client sie zum ersten Mal ändern möchte.)

Gehen Sie dann mit dem Strategiemuster, der Abhängigkeitsinjektion usw. zu den schwierigeren Themen über.

Ziehen Sie in Betracht, json in der Datenbank zu speichern, anstatt Spalten für kundeneigene Felder hinzuzufügen. Dies funktioniert möglicherweise für Sie, wenn Sie diese Felder nicht mit SQL durchsuchen müssen.

Jedes Mal, wenn Sie eine Datei in einen Zweig einchecken, MÜSSEN Sie sie mit main vergleichen und jede einzelne Änderung, einschließlich Leerzeichen, begründen. Viele Änderungen sind nicht erforderlich und können vor dem Einchecken entfernt werden. Dies kann nur darauf zurückzuführen sein, dass ein Entwickler in seinem Editor unterschiedliche Einstellungen für die Formatierung des Codes vorgenommen hat.

Sie möchten zunächst von 500 Zweigen mit vielen unterschiedlichen Dateien zu den meisten Zweigen mit nur wenigen unterschiedlichen Dateien wechseln. Und trotzdem genug Geld verdienen, um zu leben.

Möglicherweise haben Sie in vielen Jahren noch 500 Filialen, aber wenn diese viel einfacher zu verwalten sind, haben Sie gewonnen.

Basierend auf dem Kommentar von br3w5:

• Sie können jede Klasse nehmen, die für jeden Kunden anders ist
• Erstellen Sie eine "xxx_baseclass", die alle Methoden definiert, die in der Klasse von außerhalb aufgerufen werden
• Benennen Sie die Klasse um, sodass xxx xxx_clientName heißt (als Unterklasse von xxx_baseclass)
• Verwenden Sie die Abhängigkeitsinjektion, damit für jeden Client die richtige Version der Klasse verwendet wird
• Und jetzt für die clevere Einsicht, die br3w5 hatte! Verwenden Sie ein statisches Code-Analyse-Tool, um den jetzt duplizierten Code zu finden und in die Basisklasse usw. Zu verschieben

Führen Sie die oben genannten Schritte erst aus, nachdem Sie das einfache Korn erhalten haben, und führen Sie zuerst einige Klassen durch.

Stellen Sie in Zukunft die Joel-Testfragen in Ihrem Interview. Es ist wahrscheinlicher, dass Sie nicht in ein Zugunglück geraten.

Dies ist ein, ah, wie sollen wir sagen ... wirklich, wirklich schlimmes Problem zu haben. Der "Zinssatz" für diese technischen Schulden wird sehr, sehr hoch sein. Es ist möglicherweise nicht wiederherstellbar ...

Wie stark sind diese benutzerdefinierten Änderungen in den "Kern" integriert? Können Sie sie zu einer eigenen Bibliothek machen und einen einzelnen "Kern" haben und jeder einzelne Kunde ein eigenes "Add-On" haben?

Oder sind das alles sehr kleine Konfigurationen?

Ich denke, die Lösung ist eine Kombination aus:

• Das Ändern aller fest codierten Änderungen in konfigurationsbasierte Elemente. In diesem Fall hat jeder die gleiche Kernanwendung, aber Benutzer (oder Sie) schalten die Funktionalität ein / aus, legen die Namen usw. nach Bedarf fest
• Verschieben "kundenspezifischer" Funktionen / Module in separate Projekte, sodass Sie anstelle eines "Projekts" ein "Kernprojekt" mit Modulen haben, das Sie einfach hinzufügen / entfernen können. Alternativ können Sie diese Konfigurationsoptionen auch vornehmen.

Beides ist nicht trivial, als ob Sie mit über 500 Kunden hier gelandet wären. Wahrscheinlich haben Sie dabei keinen wirklichen Unterschied gemacht. Ich gehe davon aus, dass Ihre Änderungen beim Trennen eine sehr zeitaufwendige Aufgabe sein werden.

Ich vermute auch, dass Sie erhebliche Probleme haben werden, wenn Sie Ihren gesamten kundenspezifischen Code einfach trennen und kategorisieren.

Wenn es sich bei den meisten Änderungen um unterschiedliche Formulierungen handelt, empfehle ich, Fragen wie diese zur Sprachlokalisierung zu lesen . Unabhängig davon, ob Sie mehrere Sprachen vollständig oder nur eine Teilmenge ausführen, ist die Lösung dieselbe. Dies ist speziell PHP und Lokalisierung.

Dies ist eines der schlimmsten Anti-Patterns, die Sie mit einem VCS treffen können.

Der richtige Ansatz besteht darin, den benutzerdefinierten Code in einen konfigurationsbedingten Code umzuwandeln. Anschließend kann jeder Kunde eine eigene Konfiguration haben, die entweder in einer Konfigurationsdatei, einer Datenbank oder einem anderen Speicherort fest codiert ist. Sie können ganze Funktionen aktivieren oder deaktivieren, das Aussehen der Antworten anpassen usw.

Auf diese Weise können Sie eine Hauptniederlassung mit Ihrem Produktionscode behalten.

Der Zweck von Zweigen ist es, einen möglichen Entwicklungsweg zu erkunden, ohne die Stabilität des Hauptzweigs zu gefährden. Sie sollten schließlich zu einem geeigneten Zeitpunkt wieder zusammengeführt oder verworfen werden, wenn sie zu einer Sackgasse führen. Was Sie haben, sind nicht so viele Zweige, sondern vielmehr 500 Gabeln desselben Projekts, und der Versuch, die lebenswichtigen Änderungssätze auf alle anzuwenden, ist eine Sisyphus-Aufgabe.

Stattdessen sollten Sie Ihren Kerncode in einem eigenen Repository mit den erforderlichen Einstiegspunkten bereitstellen, um das Verhalten durch Konfiguration zu ändern und das Verhalten zu injizieren, das durch umgekehrte Abhängigkeiten zulässig ist .

Die verschiedenen Setups, die Sie für Clients haben, können sich dann entweder nur durch einen extern konfigurierten Status (z. B. eine Datenbank) voneinander unterscheiden oder bei Bedarf als separate Repositorys leben, die den Core als Submodul hinzufügen.

Alle wichtigen Dinge wurden hier durch gute Antworten vorgeschlagen. Ich möchte meine fünf Pence als Prozessvorschlag hinzufügen.

Ich möchte vorschlagen, dass Sie dieses Problem auf lange oder mittlere Sicht lösen und Ihre Richtlinien übernehmen, wie Sie Code entwickeln. Versuchen Sie, ein flexibles Lernteam zu werden. Wenn jemand 500 Repos haben darf, anstatt die Software konfigurierbar zu machen, ist es an der Zeit, sich zu fragen, wie Sie bisher gearbeitet haben und von nun an.

Was bedeutet:

1. Klären Sie die Verantwortlichkeiten für das Änderungsmanagement: Wenn ein Kunde einige Anpassungen benötigt, wer verkauft sie, wer lässt sie zu und wer entscheidet, wie der Code geändert wird? Wo müssen die Schrauben gedreht werden, wenn einige Dinge geändert werden müssen?
2. Klären Sie die Rolle, wer in Ihrem Team neue Repos machen darf und wer nicht.
3. Stellen Sie sicher, dass jeder in Ihrem Team die Notwendigkeit von Mustern sieht, die Flexibilität für Software ermöglichen.
4. Klären Sie Ihr Management-Tool: Woher wissen Sie schnell, welcher Kunde welche Codeannahmen hat? Ich weiß, eine "Liste von 500" klingt ärgerlich, aber hier ist eine "emotionale Ökonomie", wenn Sie wollen. Wenn Sie die Änderungen des Kunden nicht in kurzer Zeit feststellen können, fühlen Sie sich noch verlorener und gezeichneter, als müssten Sie eine Liste erstellen. Verwenden Sie diese Liste dann, um die Funktionen so zu gruppieren, wie es Ihnen die Antworten anderer Personen gezeigt haben:
   • Gruppenkunden nach kleinen / großen Veränderungen
   • gruppieren nach fachbezogenen Änderungen
   • Gruppieren nach Änderungen, die leicht zusammenzuführen sind, und Änderungen, die schwer zusammenzuführen sind
   • Finde Gruppen gleicher Änderungen an mehreren Repos (oh ja, es wird welche geben).
   • Vielleicht das Wichtigste, um mit Ihrem Manager / Investor zu sprechen: Gruppieren Sie nach teuren Änderungen und billigen Änderungen.

Dies soll in keiner Weise zu einer schlechten Druckatmosphäre in Ihrem Team führen. Ich schlage eher vor, dass Sie diese Punkte zuerst für sich selbst klären und, wo immer Sie die Unterstützung spüren, dies gemeinsam mit Ihrem Team organisieren. Laden Sie freundliche Personen zum Tisch ein, um all Ihre Erfahrungen zu verbessern.

Versuchen Sie dann, ein langfristiges Zeitfenster einzurichten, in dem Sie dieses Ding auf einer kleinen Flamme kochen. Vorschlag: Versuchen Sie, mindestens zwei Repos pro Woche zusammenzuführen, und entfernen Sie mindestens ein Repo . Sie werden vielleicht feststellen, dass Sie häufig mehr als zwei Zweige zusammenführen können, wenn Sie Routine und Kontrolle haben. Auf diese Weise können Sie in einem Jahr die schlechtesten (teuersten?) Filialen abwickeln und in zwei Jahren dieses Problem reduzieren, um eine deutlich bessere Software zu erhalten. Erwarten Sie jedoch nicht mehr, denn am Ende wird niemand Zeit dafür haben, aber Sie sind derjenige, der dies nicht länger zulässt, da Sie der Software-Architekt sind.

So würde ich versuchen, damit umzugehen, wenn ich in Ihrer Position wäre. Ich weiß jedoch nicht, wie Ihr Team solche Dinge akzeptieren wird, wie die Software dies wirklich zulässt, wie Sie unterstützt werden und was Sie noch lernen müssen. Sie sind der Software-Architekt - machen Sie es einfach :-)

Nehmen wir im Gegensatz zu all den Neinsagern einen echten Geschäftsbedarf an.

(Lieferbar ist beispielsweise Quellcode, Kunden sind aus demselben Geschäftsbereich und daher Konkurrenten, und Ihr Geschäftsmodell verspricht, ihre Geheimnisse geheim zu halten.)

Angenommen , Ihr Unternehmen verfügt über die erforderlichen Tools, um alle Niederlassungen zu verwalten. Dies sind entweder Mitarbeiter (beispielsweise 100 Entwickler, die sich für die Zusammenführung einsetzen, vorausgesetzt, dass die Veröffentlichung um 5 Tage verzögert wird, oder 10 Entwickler, wenn eine Verzögerung von 50 Tagen in Ordnung ist) oder Ein so beeindruckendes automatisiertes Testen, dass automatisierte Zusammenführungen in jedem Zweig sowohl auf Kernspezifikation als auch auf Erweiterungsspezifikation getestet werden und daher nur Änderungen, die nicht "sauber" zusammengeführt werden, menschliches Eingreifen erfordern. Wenn Ihre Kunden nicht nur für Anpassungen, sondern auch für deren Wartung bezahlen, kann dies ein gültiges Geschäftsmodell sein.

Meine (und Neinsager) Frage ist, haben Sie eine engagierte Person, die für die Lieferung an jeden Kunden verantwortlich ist? Wenn Sie beispielsweise ein Unternehmen mit 10.000 Mitarbeitern sind, kann dies der Fall sein.

Dies könnte in einigen Fällen von der Plug-in- Architektur übernommen werden. Nehmen wir an, Ihr Kern ist "trunk", Plug-ins können in "trunk" oder "branches" gespeichert werden, und die Konfiguration für jeden Kunden ist entweder eine Datei mit einem eindeutigen Namen oder befindet sich in einer Kundenniederlassung.

Plugins können zur Laufzeit geladen oder zur Kompilierungszeit eingebaut werden.

Wirklich viele Projekte werden auf diese Weise durchgeführt. Grundsätzlich gilt immer noch dasselbe Problem. Einfache Kernänderungen sind einfach zu integrieren. Konfliktänderungen müssen entweder rückgängig gemacht werden oder Änderungen an vielen Plugins sind erforderlich.

Es gibt Fälle, in denen Plugins nicht gut genug sind. In diesem Fall müssen so viele Interna des Kerns optimiert werden, dass die Anzahl der Plugin-Schnittstellen zu hoch wird, um sie verarbeiten zu können.

Idealerweise wird dies durch aspektorientierte Programmierung erledigt , wobei Trunk der Kerncode ist und Zweige Aspekte sind (dh zusätzlicher Code und Anweisungen zum Verbinden von Extras mit dem Kern).

Ein einfaches Beispiel: Sie können festlegen, dass custom foovor oder nach dem Core ausgeführt wird klass.foooder dass er ihn ersetzt oder ihn umschließt und die Eingabe oder Ausgabe ändern kann.

Dafür gibt es eine Menge Bibliotheken, aber das Problem der Zusammenführungskonflikte lässt sich nicht lösen - saubere Zusammenführungen werden von AOP gehandhabt und Konflikte erfordern immer noch menschliches Eingreifen.

Letztendlich muss sich ein solches Unternehmen wirklich mit der Wartung von Filialen befassen. Ist das kundenspezifische Feature X so weit verbreitet, dass es billiger ist, es auf den Core zu verschieben, obwohl nicht alle Kunden dafür bezahlen?

Sie lösen die Grundursache der Krankheit nicht, indem Sie sich das Symptom ansehen. Die Verwendung eines "Code-Management" -Ansatzes ist symptomatisch, löst jedoch auf lange Sicht keine Probleme. Die Hauptursache ist der Mangel an gut verwalteten Produktfunktionen, -funktionen und deren Erweiterungen und Variationen.

Ihr "benutzerdefinierter" Code repräsentiert nichts anderes als Erweiterungen der Produktfunktionen und -fähigkeiten sowie Datenfeldänderungen bei anderen.

Wie umfangreich die benutzerdefinierten Funktionen sind, wie unterschiedlich, wie kontextabhängig oder nicht, um die Codebasis Ihres Produkts zu bereinigen.

Hier spielen nicht nur Code und Version, sondern auch Produktmanagement, Produktarchitektur und Datenarchitektur eine Rolle. Ernsthaft.

Denn letztendlich ist der Code nichts anderes als Ihr Angebot an Geschäfts- und Produktfeatures / -services für Ihre Kunden. Dafür wird Ihr Unternehmen bezahlt.

Um dies besser in den Griff zu bekommen, muss man vom Standpunkt der Fähigkeiten und nicht des Codes ausgehen.

Sie, Ihr Unternehmen und Ihr Produkt können nicht alles für jedermann sein. Jetzt, da Sie eine anständige Umsatzbasis von 500 Kunden haben, ist es Zeit, auf das zu produktivieren, was Sie beabsichtigen.

Und wenn Sie mehrere Dinge anbieten, ist es sinnvoll, Ihre Produktfunktionen auf organisierte Weise zu modularisieren.

Wie breit und tief werden Ihre Produkte sein? Andernfalls führt dies zu Problemen mit der Servicequalität und zu Problemen mit der Produktverdünnung und -fragmentierung.

Wirst du ein CRM oder ERP oder Auftragsbearbeitung / Versand oder Microsoft Excel?

Ihre vorhandenen Erweiterungen müssen aufzurollen und harmonisieren, die Art und Weise eine große Software großen Zügen in und verschmilzt Produkte aus einem Startup erworben.

Sie benötigen ein starkes Produktmanagement und eine starke Datenarchitektur , die Folgendes abbilden:

• Hauptbranche, ihre Produktfunktionen und Funktionsbasis
• Benutzerdefinierte Erweiterungsfunktionen, -typen und -varianten
• Bedeutung und Variation von "benutzerdefinierten Feldern"

..zur Erstellung einer Roadmap für die Assimilation und Harmonisierung all dieser losen Produktfäden / -zweige im großen Kontext Ihrer Kernanwendung.

PS: Verbinde dich mit mir, ich kenne eine Person, die dir helfen kann, das zu beheben :)

Das kann ich nachvollziehen. Ich habe viele Projekte übernommen. Tatsächlich reparieren 90% unserer Entwicklungsarbeit solche Dinge. Nicht jeder ist perfekt, daher schlage ich vor, dass Sie die Versionskontrolle auf die richtige Art und Weise verwenden und wo Sie sind, können Sie, wenn möglich, Folgendes tun.

• Wenn ein Kunde von nun an nach einem Update fragt, verschieben Sie ihn in ein neues, gegabeltes Repository.
• Wenn Sie sie zum Master zusammenführen möchten, tun Sie dies als Erstes und lösen Sie Konflikte.
• Verwalten Sie dann ihre Probleme und Sprints mit ihrem Repository und behalten Sie diejenigen in master bei, die Sie in master starten möchten. Dies kann die Release-Zyklen stärker belasten, spart Ihnen jedoch Zeit.
• Pflegen Sie eine Hauptniederlassung des Hauptrepositorys für Neukunden, und das Hauptrepository sollte nur die Niederlassungen enthalten, an denen Sie für zukünftige Aufgaben arbeiten. Ältere Zweige können dann gelöscht werden, sobald sie in Kundenrepositorys migriert wurden.

Ich habe persönlich ein Repository von GitHub mit 40 Verzweigungen nach Bitbucket importiert und 40 Repositorys erstellt. Es dauerte nur vier Stunden. Dies waren WordPress- Theme-Variationen, also war Push and Pull schnell.

Es gibt viele Gründe, "es nicht gleich beim ersten Mal richtig zu machen", und ich denke, diejenigen, die sie schnell akzeptieren und fortfahren, "es diesmal richtig zu machen", wären immer erfolgreich.