Wie vermeide ich Branchageddon bei großen Organisationen?

10

Wie vermeiden Sie eine Branchageddon-Situation, wenn Sie mit großen Organisationen zusammenarbeiten?

Wir arbeiten mit einer Reihe großer Finanzunternehmen zusammen, deren Ansatz darin besteht, keine Software-Updates vorzunehmen, sondern nur hoch / kritische Sicherheitspatches und maßgeschneiderte Funktionen. Diese Organisationen nehmen nur Patches und benutzerdefinierte Versionen zwischen wichtigen Updates entgegen. Wichtige Updates können Jahre auseinander liegen und hohe Kosten verursachen. Dieser Ansatz führt dazu, dass wir (das Softwarehaus) eine Verzweigung unseres Codes pro Großkunde haben, die alle Kosten und Ineffizienzen einer langfristigen Verzweigung mit sich bringt.

Meine Fragen an die Community sind:

Haben Sie ähnliche Ansätze zur Akzeptanz von Updates bei Ihren Kunden erlebt?
Welche Vorschläge haben Sie, um mit diesem Ansatz zu arbeiten?
Welche Vorschläge haben Sie, um die Herangehensweisen von Organisationen an Software-Updates zu ändern?

release process branch

— Mark Wheeler
quelle

Hey Mark, es hört sich so an, als hättest du ein interessantes Dilemma. Wie verwalten Sie die Entwicklung dieser Updates pro Kunde? Entwickeln Sie sie einmalig für jeden Kunden oder entwickeln Sie sie und wenden Sie sie auf alle Kunden an?

— PrestonM

Persönlich könnte ich in dieser Situation nach einer anderen Beschäftigung suchen. Das klingt nach einem Sicherheitsvorfall, der darauf wartet, passiert zu werden ... Ich kann Ihnen sagen, dass der Appliance-Anbieter, für den ich gearbeitet habe, einen schwerwiegenden Fehler hatte, der in einem Update behoben wurde, zu dem sie Berichten zufolge nicht gehen konnten. Sie wollten eine benutzerdefinierte Lösung. Wir weigerten uns, ihnen eine zu erstellen, und sagten ihnen, dass sie ihre Geschäftsrichtlinien korrigieren müssten - wir würden keinen benutzerdefinierten Hotfix für einen Fehler veröffentlichen, den wir bereits gepatcht hatten, nur um interne politische Probleme zu vermeiden.

— James Shewey

Wir verwalten die benutzerdefinierten clientspezifischen Updates über mehrere Codezweige und Cross-Fixing-Sicherheitsupdates für alle Zweige sowie Cross-Fixing-Branch-Code zurück in den Trunk. Oft nimmt Kunde A keine Updates für Kunde B in seiner Filiale entgegen, sondern nur seine eigenen Updates und Sicherheitspatches. Dies ist auf den Wunsch nach Stabilität in ihrer Branche zurückzuführen, sodass sie nur die für sie relevanten Aktualisierungen testen müssen. Sie nehmen Trunk-Updates seltener vor (dh Monate bis Jahre), wenn sie bereit sind, vollständige Testwiederholungen durchzuführen, was Monate dauern kann. Automatisierte Tests könnten die Antwort sein!

— Mark Wheeler

3

Bieten Sie, wie Michael erwähnte, eine Standardlösung an, die auf Release-Versionen / -Nummern basiert und eine für Ihre Branche relativ lange Lebensdauer hat (möglicherweise verschachtelt mit einer oder mehreren Zwischenversionen mit kürzerer Lebensdauer, wenn dies für Ihre typischen Kunden sinnvoll ist).

Geben Sie Ihren Kunden die Möglichkeit, sich auf diesen Standard-Release-Track einzulassen, möglicherweise mit einer angemessenen Migrationsfrist.

Wenn sie auf einer vollständig benutzerdefinierten Strategie für den Filial-Support bestehen, berechnen Sie diese einfach entsprechend, um alle zusätzlichen Kosten für das Angebot eines solchen benutzerdefinierten Supports ordnungsgemäß zu decken. Dies ist nur wirtschaftlich sinnvoll. Einige Kunden werden migrieren, um ihre Kosten zu senken (wodurch Sie die Anzahl der benutzerdefinierten Filialen reduzieren können), andere nicht.

Die variable Support-Abrechnung, die mit dem Alter der Release-Versionen, aus denen die benutzerdefinierten Filialen stammen, zunehmend zunimmt, kann auch ein Anreiz für Kunden sein, schneller auf neuere Filialen zu migrieren und die älteren benutzerdefinierten Filialen schneller zu schließen. Dies kann dazu beitragen, die Anzahl der benutzerdefinierten Filialen pro Kunde zu verringern - wenn Sie Kunden haben, die gleichzeitig mehrere Versionen Ihrer Software ausführen.

Stellen Sie sicher, dass Sie nicht in die Falle geraten, vollständige Verzweigungszusammenführungen von / zu einem der Release-Zweige (sowohl Standard- als auch benutzerdefinierte) durchzuführen. Alle Änderungen an diesen sollten entweder individuell entwickelt oder von Kirschen ausgewählt und zusammengeführt werden.

Da sich jeder dieser Zweige allmählich voneinander unterscheidet, nimmt die Anzahl der Hotfixes, die angepasst / individuell entwickelt werden müssen, exponentiell zu (das Zusammenführen von einfachen Kirschpickeln schlägt fehl). Sie müssen die Entwicklungskosten für diese berücksichtigen.

Wenn im Bild keine (signifikanten) Zweigzusammenführungen vorhanden sind, können (und sollten, ich kann ihre Bedeutung nicht genug betonen) vollautomatische CI / CD-Pipelines für diese Zweige erstellt werden, zusammen mit einem guten Hotfix-Tracking / Management-System, das die Hotfix-Bereitstellung ermöglicht nur Routine (oder fast).

— Dan Cornilescu
quelle

Dan - so offensichtlich und einfach, aber es macht vollkommen Sinn. Geld bringt die Welt in Bewegung und sollte wiederum dazu beitragen, die Kosten für langlebige Filialen zu kompensieren oder Kunden zu ermutigen, ein Upgrade durchzuführen und in der Nähe des Kofferraums zu bleiben. Vielen Dank für Ihren guten Rat.

— Mark Wheeler

1

Wenn Sie Filialen pro Version anstatt pro Kunde pflegen, kann dies möglicherweise dazu beitragen, die Anzahl der Filialen zu verringern?

Andernfalls besteht die einzige Möglichkeit, sich wirklich davon zu lösen, darin, die Software selbst zu hosten und zu einem SaaS-Modell zu wechseln, in dem Sie nur eine Version davon verwalten können.

— Michael Pereira
quelle

Leider arbeiten unsere Kunden aufgrund der Finanzdaten, mit denen sie arbeiten, häufig in sehr heruntergefahrenen Umgebungen, sodass ein SaaS-Modell nicht akzeptabel wäre.

— Mark Wheeler