Quelle est une manière réaliste de gérer les correctifs logiciels spécifiques au client?

16

J'essaie de rassembler des moyens efficaces pour que d'autres résolvent le problème suivant. Au travail, nous avons été contraints de publier un correctif logiciel (à installer sur les systèmes des utilisateurs finaux) que nous ne voulons voir que pour un client spécifique. Le code personnalisé se trouve dans sa propre branche de contrôle de source. Le problème est que nous avons deux lignes de code parallèles (et construisons des scripts) à synchroniser, et chaque fois que nous corrigeons le code d'origine, nous devons corriger et tester le code spécifique au client.

Je suis curieux, comment les autres organisations gèrent-elles ce scénario? Nous sommes ouverts aux solutions commerciales et pas seulement techniques (liées au contrôle des sources). Par exemple, nous avons parlé de dire au client qu'il ne peut pas recevoir de mises à jour sur cette branche.

Notre stratégie de branchement est la suivante (basée sur le Guide de branchement Visual Studio TFS , bien que nous utilisions Subversion pour cela) entrez la description de l'image ici

version-control business release-management

— Vimes
source

Si vous utilisiez hgou gitje pourrais suggérer que vous envisagiez d'utiliser des files d'attente de correctifs ( extension de files d'attente Mercurial ou Stacked Git ), mais je ne sais pas si TFS a quelque chose de similaire.

— Mark Booth

J'aurais peut-être dû préciser que nous utilisons Subversion même si nous utilisons une stratégie de branchement suggérant TFS: P Les files d'attente de correctifs réduiraient-elles les tests nécessaires? Il semble que ce soient des correctifs de contrôle de source? Nous traitons des correctifs que le client installe sur les systèmes des utilisateurs finaux.

— Vimes

2

Une solution commerciale serait: ne le faites pas.

— JeffO

@JeffO good call =) Dans tous les cas, existe-t-il un moyen de faire de cela un commutateur d'exécution piloté par les données?

— Patrick Hughes

1

@JohnB - Désolé, je ne sais pas, mais si vous avez des correctifs source, votre système de construction devrait être en mesure d'automatiser les tests, en plus de conserver les correctifs par client en dehors de cela svn, ils n'encombrent pas votre flux de travail normal. Si les files d'attente de correctifs semblent utiles, vous pouvez les essayer en utilisant git-svn ou hgsubversion . L'utilisation d'un frontal DVCS pour lisser un flux de travail délicat svnpourrait même encourager les gens à envisager de passer à un gros DVCS, pour obtenir tous les autres avantages.

— Mark Booth

5

Lorsque vous commencez à distribuer des correctifs spécifiques au client, vous avez immédiatement créé une nouvelle version de votre produit qui doit être maintenue à côté de celui-ci. Cela signifie que les modifications doivent être propagées entre les deux versions. Les correctifs spécifiques au client sont généralement des personnalisations qui doivent appartenir au client, y compris le code source.

Il semble peu probable qu'un correctif pour corriger quelque chose ne parvienne pas à la branche principale à moins qu'il ne s'agisse d'une solution temporaire moins qu'optimale pour un problème immédiat. Si tel est le cas, le correctif devra uniquement être maintenu jusqu'à ce que le correctif attendu soit intégré à la ligne principale.

— Charles Lambert
source

5

Il me semble que la clé est "visible" - qu'en est-il de ne pas avoir du tout de branche de code séparée, mais plutôt d'une option de configuration qui change le comportement?

— Loren Pechtel
source

Cela pourrait fonctionner pour des personnalisations simples, mais plus complexes pourraient rendre le produit plus gênant et instable pour tous les clients.

— FrustratedWithFormsDesigner

3

@FrustratedWithFormsDesigner Les personnalisations complexes pour les clients individuels représentent une négligence grave dans la gestion et la conception des produits. Toute solution qui nécessite une succursale distincte pour un seul client pour un produit représente une insuffisance flagrante du produit pour répondre à tous les besoins des clients et une mauvaise gestion de la part du propriétaire du produit.

— maple_shaft

2

J'ai également vu cette morsure mon ancien employeur à maintes reprises. C'est juste une mauvaise pratique, mais c'est généralement quelque chose que la direction veut et ne reculera pas. En particulier, si vous utilisez Subversion, ce n'est qu'un cauchemar qui ne disparaîtra pas - garder le code synchronisé fera mal, maintes et maintes fois.

— Steve Hill

1

@maple_shaft - Mais avez-vous pensé à poser la question "avez-vous déjà utilisé la branche de code pour implémenter l'internationalisation"?

— psr

3

@maple_shaft - Je plaisantais, mais en fait, c'était mon point, utiliser la branche pour gérer l'internationalisation est au moins aussi mauvais que les branches spécifiques au client. Ce n'est pas théorique dans le sens où vous ne voulez probablement pas travailler dans un tel endroit non plus. Il est théorique que j'allais assez loin du sujet.

— psr

3

Voyez-vous cela comme une chose à court ou à long terme? Le fait est que l'entreprise a déjà décidé d'accueillir ce client, donc à court terme, c'est déjà une décision commerciale qui doit être principalement résolue par des pratiques commerciales (accepter le coût supplémentaire / facturer le client pour le coût).

Si à long terme, vous réaliserez probablement des économies si vous remodelez le logiciel pour qu'il s'adapte facilement aux besoins des clients via la configuration (ou l'installation, etc.).

S'il s'agit d'un terme relativement court, vous fusionnerez bientôt ces modifications dans la branche principale / développement et tous les utilisateurs verront également les changements, alors il sera probablement acceptable de travailler dans les limites de votre situation actuelle. Comme je l'ai dit, la décision à prendre aurait dû être prise lorsque la décision d'accommoder le client a été prise.

Longue histoire courte. À long terme, corrigez-le techniquement, traitez-le à court terme.

Bien sûr, il y a un point où c'est un tirage au sort. Si vous en êtes là, je ferais ce que les développeurs préfèrent.

— ElGringoGrande
source

2

Nous utilisons également la subversion - et nous rencontrons exactement un tel scénario.

Voici quelques points clés à retenir:

S'il est nécessaire d'éviter les succursales spécifiques pour les clients, le besoin doit être minimisé autant que possible; demandez toujours s'il est possible de généraliser la solution qui pourrait bien fonctionner pour tous.
Les succursales spécifiques au client doivent provenir d'une nouvelle version. Supposons que vous ayez une version 1.2 et que vous ayez dérivé de la version 1.2.1 à 1.2.11 - les branches client devraient être autorisées à tous les correctifs, donc la branche client doit rester compatible par rapport à la version principale.
Une branche spécifique au client doit être créée une nouvelle fois lorsque vous démarrez une nouvelle version non compatible. La partie malheureuse est que vous pourriez avoir besoin de refaire le travail. Une solution peut être de créer tous les correctifs à partir des succursales clientes qui doivent être extraits et tout ce qui reste compatible peut être appliqué à la nouvelle succursale client.
Toujours, en aucun cas, ne devez repousser les modifications spécifiques au client pour libérer la branche ou le tronc. Cependant, idéalement, on devrait essayer de généraliser le travail de telle manière que ce travail spécifique au client soit réduit.

J'ai essayé de rassembler ces idées pour les montrer diagramme ci-dessous :

— Dipan Mehta
source

1

Que diriez-vous d'introduire un mécanisme d'extension dans votre code?

Votre code principal a:

class Foo
{
}

Lorsque le programme se lance, il recherche DLL / équivalent moral, dans son dossier de démarrage pour les personnalisations locales. S'il en trouve un, il se charge et il peut contenir une version spécifique à l'entreprise de Foo

class FooForABC : Foo
{
}

FooForABC implémente le même comportement que Foo mais remplace les fonctions nécessaires pour fournir le comportement spécifique dont ABC a besoin. La technique doit être suffisamment flexible pour gérer tout scénario que vous devez prendre en charge.

— Winston Ewert
source