Comment éviter le branchageddon avec les grandes organisations?

10

Comment éviter une situation de branchageddon lorsque vous travaillez avec de grandes organisations?

Nous travaillons avec un certain nombre de grandes organisations financières dont l'approche consiste à ne pas mettre à jour les logiciels, mais uniquement les correctifs de sécurité élevés / critiques et les fonctionnalités sur mesure. Ces organisations prendront uniquement des correctifs et des versions personnalisées entre les mises à jour majeures. Les mises à jour majeures peuvent être espacées de plusieurs années et entraîner des coûts élevés. Cette approche nous amène (la maison du logiciel) à avoir une branche de notre code par client principal, qui supporte tous les coûts et les inefficacités d'une branche à long terme.

Mes questions à la communauté sont:

Avez-vous rencontré des approches d'acceptation des mises à jour similaires de la part de vos clients?
Quelles suggestions avez-vous pour aider à travailler avec cette approche?
Quelles suggestions avez-vous pour aider les organisations à changer les approches de prise de mises à jour logicielles?

release process branch

— Mark Wheeler
source

Hé Mark, on dirait que tu as un dilemme intéressant. Comment gérez-vous le développement de ces mises à jour par client? Les développez-vous de manière ponctuelle pour chaque client, ou est-ce quelque chose que vous développez et appliquez à tous les clients?

— PrestonM

Personnellement, je pourrais chercher un autre emploi dans cette situation. Cela ressemble à un incident de sécurité en attente de se produire ... Je peux vous dire que pour le fournisseur de l'appliance pour lequel je travaillais, il y avait un bogue majeur qui a été corrigé dans une mise à jour auquel il n'aurait pas pu aller. Ils voulaient une solution personnalisée. Nous avons refusé d'en créer un et leur avons dit qu'ils devaient aller corriger leurs politiques commerciales - nous n'allions pas lancer un correctif personnalisé pour un bogue que nous avions déjà corrigé juste pour éviter les problèmes politiques internes.

— James Shewey

Nous gérons les mises à jour spécifiques au client personnalisé via plusieurs branches de code et cross-fixant les mises à jour de sécurité à toutes les branches, et cross-fixant le code de branche dans le tronc. Souvent, le client A ne prendra pas les mises à jour du client B dans sa succursale, il ne prendra que ses propres mises à jour et correctifs de sécurité. Ceci est motivé par un désir de stabilité dans leur branche et ils n'ont donc qu'à tester les mises à jour qui les concernent. Ils prennent les mises à jour de tronc moins fréquemment (c'est-à-dire des mois ou des années) lorsqu'ils sont prêts à exécuter des réexécutions de test complètes, ce qui peut prendre des mois. Les tests automatisés pourraient être la réponse!

— Mark Wheeler

3

Comme Michael l'a mentionné, proposez une solution standard basée sur des versions / numéros de version, avec une durée de vie raisonnablement longue pour votre industrie (peut-être entrelacée avec une ou plusieurs versions intermédiaires de durée de vie plus courte, si cela est logique pour vos clients typiques).

Donnez à vos clients la possibilité de se lancer dans cette voie de publication standard, peut-être avec une date limite de migration décente en place.

S'ils insistent sur une stratégie d'assistance complète pour les succursales, il suffit de les facturer en conséquence, afin de couvrir correctement tous vos coûts supplémentaires pour offrir une telle assistance entièrement personnalisée - cela n'a de sens que sur le plan commercial. Certains clients migreront pour réduire leurs coûts (ce qui vous aidera à réduire le nombre de succursales personnalisées), d'autres non.

La facturation de l'assistance variable, augmentant progressivement avec l'âge des versions de publication dont les branches personnalisées sont originaires, peut également inciter les clients à migrer plus rapidement vers les nouvelles branches, ce qui permet de fermer plus rapidement les anciennes branches personnalisées. Cela peut aider à réduire le nombre de succursales personnalisées par client - si vous avez des clients qui exécutent simultanément plusieurs versions de votre logiciel.

Assurez-vous que vous ne tombez pas dans le piège de la fusion complète des branches de / vers l'une des branches de publication (standard et personnalisée), toutes les modifications doivent être développées individuellement ou fusionnées.

Étant donné que chacune de ces branches divergera progressivement les unes des autres, le nombre de correctifs nécessitant une personnalisation / un développement individuel augmentera de façon exponentielle (la fusion simple avec un choix de cerises échouera). Vous devez en prendre en compte le coût de développement.

Sans fusion (significative) de branche dans l'image, vous pouvez (et je ne devrais pas insister suffisamment sur son importance) créer des pipelines CI / CD entièrement automatisés pour ces branches, accompagnés d'un bon système de suivi / gestion de correctifs en place, ce qui rend la livraison de correctifs juste de la routine (ou presque).

— Dan Cornilescu
source

Dan - si évident et simple mais c'est parfaitement logique. L'argent fait tourner le monde et devrait à son tour aider à nous compenser le coût des succursales à longue durée de vie ou à encourager les clients à se moderniser et à rester proches du coffre. Merci pour vos bons conseils.

— Mark Wheeler

1

Peut-être que si vous mainteniez des succursales par version plutôt que par client, cela pourrait aider à réduire leur nombre?

Sinon, la seule façon de vraiment s'en éloigner est de pouvoir héberger le logiciel vous-même et de passer à un modèle SaaS où vous ne pourrez en conserver qu'une seule version.

— Michael Pereira
source

Malheureusement, nos clients opèrent souvent dans des environnements très fermés en raison des données financières avec lesquelles ils travaillent, donc un modèle SaaS ne serait pas acceptable.

— Mark Wheeler