Meine Firma hat die Idee, unsere Versionsnummern um eine weitere Kerbe zu erweitern (z. B. von major.minor.servicepack zu major.minor.servicepack.customerfix), um kundenspezifische Korrekturen zu ermöglichen.
Dies erscheint mir als eine schlechte Idee an der Oberfläche, da meine Erfahrung ist, je verzweigter ein Produkt ist (und ich glaube, die Kunden-Fixes sind Zweige der Code-Basis), je mehr Overhead, desto mehr Aufwand und letztlich weniger produktiv wird die Entwicklungsgruppe.
Ich habe eine Menge Risiko-Produktivitäts-Diskussionen gesehen, aber nur zu sagen: "Ich denke, das ist eine schlechte Idee" reicht nicht aus. Welche Literatur gibt es über die tatsächlichen Kosten, zu risikoscheu zu werden und ein schweres, kundenspezifisches Quellcodeverzweigungsentwicklungsmodell zu übernehmen?
Eine kleine Erläuterung. Ich erwarte, dass dieses Modell bedeutet, dass der Kunde die Kontrolle darüber hat, welche Bugfixes in seine eigene Privatfiliale gelangen. Ich denke, dass sie selten auf den allgemeinen Stamm aufrüsten würden (es existiert vielleicht nicht einmal in diesem Modell). Ich meine, warum würdest du, wenn du deine eigene Realitätsblase kontrollieren könntest?
Kann nicht mit Literatur helfen, aber kundenspezifische Verzweigung ist eine schlechte Idee. Kenne ich schon. Das Debuggen war reine Hölle, denn natürlich mussten Sie alle diese kundenspezifischen Versionen verfügbar haben, um den Fehler zu reproduzieren ... einige Zeit später musste die Firma eine abgeschlossen
Geh nicht dorthin.
Ich stimme zu, dass der Aufwand für die Bearbeitung von Kunden-Fixes generell hoch ist, aber ich würde nicht sagen, tu es nicht.
Ich würde sagen, den Kunden einen Arm und ein Bein (und einige) aufladen, wenn sie so viel Aufmerksamkeit wollen. Ansonsten machen Sie keine Kundenfilialen.
Sie beschreiben die Änderungen, die in den Kundenzweig als "Fixes" gehen. Da es sich um Fixes handelt, gehe ich davon aus, dass sie auch im Kofferraum gemacht werden und eigentlich nur fortgeschrittene Auslieferungen von zukünftigen Bugfixes sind. Wenn dies der Fall ist, dann erstellen Sie einfach ein neues "Servicepack" (aus der Frage: major.minor.servicepack) und geben Sie diese Version an den Kunden weiter.
Auf meinen Reisen habe ich persönlich keine bestimmte Literatur für die meisten guten Praktiken gesehen, obwohl ich vermute, dass da draußen eine Menge Zeug ist.
Versionsnummern bieten einen wirklich einfachen Mechanismus, um bestimmte Versionen mit bestimmten Codeänderungen zu verknüpfen. Technisch spielt es keine Rolle, wie viele Level in der Versionsnummer enthalten sind, solange die Entwickler fleißig versichern, dass es für jede "einzigartige" Version eine "eindeutige" Versionsnummer gibt.
Logic schreibt vor, dass zur Begrenzung der Support-Kosten (die riesig sind, oft schlimmer als die Entwicklung), eine vernünftige Organisation es vorziehen würde, die geringste Anzahl von "einzigartigen" Versionen im Feld zu haben. Man wäre fantastisch, aber in der realen Welt gibt es normalerweise ziemlich viele. Es ist ein Kosten-Nutzen-Problem.
Normalerweise zeigt die erste Zahl an, dass diese Serie von Versionen nicht abwärtskompatibel ist. Die nächste Zahl sagt, dass es meistens ist, aber ein paar Dinge haben sich geändert und die letzte Zahl sagt, dass einige Sachen repariert worden sind, aber die Dokumente sind alle wahr. Auf diese Weise benötigen Sie keine vierte Nummer, auch wenn Sie auf Anfrage einer Untergruppe Ihrer Kunden einige spezifische Korrekturen vorgenommen haben. Die Entscheidung, kundenorientierter zu werden, sollte keinen Einfluss auf Ihr Nummerierungsschema haben (und daher ist es eine schlechte Idee).
Die Verzweigung basierend auf Kundenanfragen ist absoluter Wahnsinn. Ein Hauptstamm ist wichtig, so dass jedes Mal, wenn Sie sich verzweigen, massive technische Schulden entstehen. Verzweigen Sie sich genug, und Sie können das Interesse nicht mehr leisten.
Ich bin mir nicht sicher über die Literatur, aber ... wenn es sogar eine Chance gibt, dass Sie kundenspezifische Korrekturen unterstützen, scheint es sinnvoll, zumindest eine Verzweigungs- und Versionierungsstrategie zu haben. Obwohl ich hoffen würde, dass die Strategie nie benutzt wird.
Ich schätze, die Gefahr besteht darin, dass Sie mit einer Kultur konfrontiert werden, in der kundenspezifische Lösungen akzeptiert werden und die Norm sind, anstatt das eigentliche Problem anzugehen, das zur Notwendigkeit der Fehlerbehebung geführt hat.
Ich schätze, die tatsächlichen Kosten hängen weitgehend davon ab, ob es sich nur um einen Zwischenfehler handelt, um einen Kunden vor der nächsten Veröffentlichung glücklich zu machen, oder ob es sich eher um eine einmalige Anpassung handelt. Wenn es nur das erstere ist, und die Menge nicht zu hoch ist, würde ich nicht zu beschäftigt sein. Aber wenn ich die Anpassungen anpasse, wäre ich wahnsinnig verängstigt.
Wenn Sie eine Möglichkeit finden, ein einzelnes Produkt zu kompilieren und die Funktionen eines jeden Kunden in seiner "Konfiguration" eines zentralen Builds ein- / auszuschalten, die es wert ist, herausgefunden zu werden.
Etwas Ähnliches kann am besten über ein profil / config / rollenbasiertes Setup durchgeführt werden.
Möglicherweise müssen Sie die Anpassungen eines Clients an einem anderen sichern, oder vielleicht können alle davon profitieren. Dieser Teil liegt an dir.
Auf diese Weise können Sie benutzerdefinierte Ansichten, benutzerdefinierte Codes, benutzerdefinierte Rollen, benutzerdefinierten Code usw. erstellen. Aber sie sind Teil eines Projekts.
Pflegen Sie nicht mehrere Codebasen desselben Produkts um jeden Preis. Ich habe es einmal getan, und eine Stunde dauern dauert mindestens 1 Stunde für jedes System, wenn es an der schlechtesten Stelle ist. Es ist Selbstmord.
Teilen Sie, was Sie tun!
Nach meiner Erfahrung ist der Wendepunkt erreicht, wenn es schwierig wird zu erklären, wie Bugfixes durch die Zweige verbreitet werden sollten.
Die Verzweiflung der Hölle ist ein Problem, weil die Leute den Überblick verlieren, was in welchem Zweig ist. Wenn die Propagierungsregeln zu komplex sind, fangen die Leute an, Fehler zu machen, während sie Änderungen zwischen den Zweigen propagieren, und so entsteht eine verzweigte Hölle.
Wenn der Zweig "Cisco" einen Fehler ausgelöst hat und wir ihn beheben, sollten wir den Fix dann auf das aktuelle Release des "IBM" Zweiges oder nur auf das nächste Release des "IBM" Zweigs propagieren? Was ist, wenn IBM den gleichen Fehler hat? Was ist, wenn IBM die Funktion, die den Fehler enthält, nicht einmal verwendet? Was ist, wenn IBM später den gleichen Fehler wie hohe Priorität verursacht? Mit mehreren Kundenzweigen sind Vermehrungsregeln nie einfach, so dass sie die Verzweigung der Hölle garantieren.
Tags und Links branch versioning