Dans une architecture distribuée, pourquoi est-il difficile de gérer les versions?

Question

Je vois cela maintes et maintes fois. Le responsable des tests UAT souhaite que la nouvelle version soit prête à être testée d'ici vendredi. L’une des premières questions posées lors de la réunion de mise à l’essai est la suivante: & "Quelle version vais-je tester?? &"; (ce qui est une bonne question à poser). La pièce se tait, puis quelqu'un reviendra avec & "Tous les assemblages ont leur propre version, il suffit de cliquer avec le bouton droit de la souris et de regarder les propriétés ... &";

Du point de vue des responsables des tests, cela ne sert à rien. Ils veulent une version / étiquette / tag sur tout qui leur indique ce sur quoi ils travaillent. Ils veulent que cette information soit facilement disponible.

J'ai vu des solutions dans lesquelles la version de différentes zones d'un système était stockée dans un magasin de données, puis affichée dans la boîte de dialogue de l'application principale. Le problème est que cela doit être maintenu.

Quelles solutions avez-vous trouvées pour résoudre ce problème persistant?

EDIT. Le système distribué comprend VB6, Classic ASP, VB.Net, C #, Web Services (tous départements confondus, quelle version utilisons-nous?), SQL Server 2005.

Answer 1

Je pense que le problème est que vous et votre responsable des tests parlez de deux choses différentes. Les versions d'assemblage conviennent parfaitement aux assemblages, mais votre responsable des tests parle d'une version de niveau supérieur, une & "Version système &"; Si vous voulez. Au moins, c’est ce que j’ai lu de votre message.

Dans de telles situations, vous devez mapper tous vos différents assemblages de composants dans une version système. Vous dites quelque chose du type & "; La version 1.5 du système est composée de Foo.Bar.dll v1.4.6 et de Baz.Qux.dll v2.6.7 et (etc.) &"; Bon sang, dans un système distribué, vous souhaiterez peut-être différentes versions pour chacun de vos services, lesquelles peuvent être composées de différentes versions de fichiers .dll. Vous pourriez dire, par exemple: & Quot; La version 1.5 du système est composée du service Foo v1.3, composé de Foo.dll v1.9.3 et de Bar.dll v1.6.9, et du service Bar v1. .9, qui est composé de Baz.dll v1.8.2 et de Qux.dll v1.5.2 et (etc.) & Quot ;.

Effectuer des tâches de ce type revient généralement à l'architecte logiciel et / ou au responsable de la compilation de votre organisation.

Il existe un certain nombre d’outils que vous pouvez utiliser pour traiter ce problème qui n’ont rien à voir avec la langue de votre choix. Mon favori personnel est actuellement Jira , qui, en plus du suivi des bogues, offre une excellente gestion des versions du produit. et soutien à la cartographie routière.

Answer 2

Peut-être voudriez-vous jeter un oeil à la page qui explique certaines manières intégrer des versions cohérentes dans votre processus de construction.

Answer 3

Plusieurs facteurs contribuent au problème. Voici ce que je peux vous dire:

L'un des avantages d'une architecture distribuée est que nous développons un potentiel de réutilisation considérable en créant des services et en publiant leurs interfaces sous une forme ou une autre. Cela signifie donc que les versions d'une application cliente ne sont pas nécessairement étroitement synchronisées avec les versions des services sous-jacents. Ainsi, une nouvelle version d'une application métier peut être publiée qui utilise le même ancien service fiable que celui utilisé depuis un an. Comment appliquer ensuite une seule étiquette de version dans ce cas?

Néanmoins, c’est une question légitime, mais qui nécessite une réponse non triviale pour avoir un sens.

Answer 4

N'utilisez pas la numérotation de version basée sur la génération pour autre chose que des références internes. Lorsque le responsable de l'UAT pose la question, vous dites & "Vendredi * *!".

.

La seule astuce consiste alors à vous assurer que l'étiquetage est effectué de manière fiable dans votre contrôle de code source.

* insérez ici le cachet / horodatage approprié

Answer 5

Nous utilisons .NET et Subversion. Tous nos assemblages d'application partagent un numéro de version, dérivé des numéros de révision majeure et mineure mis à jour manuellement et du numéro de révision de Subversion (<major>.<minor>.<revision>). Nous avons une tâche de pré-construction qui met à jour ce numéro de version dans un fichier AssemblyVersionInfo.vb partagé. Ensuite, lorsque les testeurs demandent le numéro de version, nous pouvons leur donner le numéro complet en 3 parties ou simplement la révision de la sous-version. Les bibliothèques que nous consommons ne changent pas ou le changement ne concerne pas le testeur.