Utiliser les versions floues pour publier des fonctionnalités

Votre département propose à ses utilisateurs (interfaces Web ou autres) un ensemble de fonctionnalités sous forme de Web Services (par exemple), permettant de gérer votre métier. Celui-ci évoluant rapidement, ou étant en pleine phase de construction, vous mettez régulièrement à jour ces fonctionnalités.

Comment permettre à vos utilisateurs d'avoir accès à ces mises à jour sans pour autant leur demander de mettre à jour systématiquement leur code ou leur client de connexion à vos Web Services ?

En utilisant les versions floues.

Les mises à jour que vous publiez sont (normalement) toutes soumises à un numéro de version, que je prendrais sous la forme majeure.mineure.révision (ex : 1.5.16) pour l'exemple. L'astuce réside dans le fait de ne faire apparaître qu'une partie seulement de ce numéro de version dans l'adresse des Web Services, que vous fournissez à vos utilisateurs.

Par exemple, vos Web Services sont accessibles à l'adresse http://monServeur.com/mesWebServices.

Si vous laissez l'adresse sous cette forme, toute modification de l'interface (WSDL) de ces Web Services entraînera obligatoirement une mise à jour du côté de vos utilisateurs, ce qui peut s'avérer problématique pour vos utilisateurs (modification de leur code, compilation, recettage et mise en production seront alors nécessaires). En plus de cela, la mise en production de vos Web Services et de leur propre application devront être parfaitement simultanées, de façon à ne pas impacter leurs services. Si vous avez plusieurs clients, cette opération relève de l'impossible.

Inversement, vous pouvez faire apparaître le numéro de version complet dans l'adresse de vos Web Services, ce qui pourrait donner par exemple : http://monServeur.com/mesWebServices-1.5.16. A chaque nouvelle publication, vous prévenez l'ensemble de vos clients qui peuvent alors choisir ou non d'utiliser cette version supérieure. Cette solution présente l'avantage de laisser vos utilisateurs maîtres de leurs évolutions, ce qui est un point particulièrement important. En revanche, s'ils veulent bénéficier de toutes les évolutions, y compris les corrections de bugs (n'incrémentant normalement que la révision), ils devront effectuer autant de mises en production que vous en faites. De plus, vous devrez maintenir l'ensemble des versions que vous publier et disposer d'un serveur suffisamment puissant pour toutes les faire tourner.

La solution...

Une solution intermédiaire consiste à flouter la version complète de façon à ne faire apparaître que la partie majeure et mineure. Dans le cas de notre exemple, vos Web Services seraient accessibles à l'adresse http://monServeur.com/mesWebServices-1.5.x ou http://monServeur.com/mesWebServices-1.5. Dans ce cas, vous pourrez faire évoluer votre version en cours (la 1.5), c'est-à-dire y apporter des corrections de bugs ou des évolutions mineures, et en faire profiter vos utilisateurs sans leur demander la moindre modification.

Personnellement, j'utilise la version floutée avec un "-x" de façon à faire comprendre clairement à mes utilisateurs que cette version n'est pas figée et que des évolutions, transparentes pour lui, peuvent avoir lieu.

Les mises à jour plus importantes (modification de l'interface par exemple : nouvelles méthodes ou modification des types utilisés) seront publiées sous un numéro de version dont la partie mineure (ou majeure) sera incrémentée. Le choix de passer à cette nouvelle mouture est alors laissé à vos utilisateurs.

Un autre avantage de cette solution est de permettre tout en douceur le passage même obligatoire) à une version supérieure. Il vous suffit alors de laisser les deux versions tourner en parallèle pendant quelques temps et de donner à vos utilisateurs une date de retrait de la version obsolète. Ils auront alors le temps d'effectuer la mise à jour.

Notez que cette solution peut très bien être mise en place avec d'autres formes d'application que des Web Services. Une interface Web peut, par exemple, subir le même sort...

Reste à définir ce que vous considérez comme une évolution majeure, mineure ou une simple révision... Mais cela fera l'objet d'un autre billet...

Vous pouvez consulter cet article particulièrement intéressant, abordant également la notion de publication des releases et leur utilisation par les clients (merci à Tanguy pour le lien).