Pascalleclercq's Blog

28/02/2010

Versionning et compatibilité ascendante

Filed under: architecture,OSGi — pascalleclercq @ 11:22
Tags: , , , ,

Je rencontre encore trop souvent des personnes qui bloquent inutilement les évolutions de leur système d’information par crainte de dysfonctionnement ou d’effort d’intégration trop important. Le métier lui,  souhaite que l’informatique s’adapte rapidement à de nouvelles exigences pour un coût raisonnable (Le fameux “Time to market”).

Il existe pourtant quelques bonnes pratiques permettant de satisfaire cette exigence. Celles-ci sont trop souvent méconnues. Commencez par réfléchir à l’architecture applicative de votre SI afin de dégager des contrats de services pérennes et gérez la compatibilité ascendante en vous appuyant sur une politique de versionning lisible. Enfin, garantissez la compatibilité ascendante en exécutant différents tests d’intégrations sur les différentes versions concernées

Architecture applicative.

Inutile d’ espérer répondre de manière satisfaisante aux défis cités ci-dessus sans avoir réfléchi à l’architecture applicative. Il s’agit ici d’organiser les données et traitement d’un Système d’information en ensembles cohérents.

Prenons un exemple basique, un système d’information constitué de 3 briques  :

– Une brique « connaissance du client »

– Une brique de référencement de produit.

– Une brique de commande client.

Dans les SI d’informations « réels », il existe bien plus de briques fonctionnelles. Ce qui rend l’objet de cet article encore plus pertinent.

Programmation par contrat.

La programmation par contrat permet de définir les points de jonctions  de vos briques applicatives.

Pour les amateurs de webservices, un contrat de service se définit à l’aide d’un WSDL.

Au minimum, un contrat de service se concrétise par une interface (ici IClientService) auquel il faut ajouter les objets échangés au travers de ce service.

image

Gestion de la compatibilité ascendante.

Cette notion est trop souvent éludée ou méconnue. Pourtant elle est fondamentale si vous souhaitez répondre rapidement et efficacement à de nouvelles exigences.

Par exemple, si vous souhaitez ajouter un support de communication avec votre client (ici une adresse de Facturation). Sans la gestion de la compatibilité ascendante, soit vous gérez plusieurs versions de la brique « connaissance du client », soit vous obligez la brique « commande client » à être re-livrée. Avec le temps et les nouvelles demandes, l’effort de maintenance peut évoluer de manière exponentielle. La solution passe inévitablement par la gestion de la compatibilité ascendante.

image

La fonctionnalité supplémentaire (ajout d’une adresse de facturation) ne pose pas de problème au code client déjà compilé, recetté et livré. La montée de version peut se faire très facilement sans risque de perturber le système existant.

Il existe de nombreux avantages à gérer la compatibilité ascendante :

  • Les autres briques du SI peuvent monter de version à leur rythme.
  • Cela permet de limiter le nombre de branches à maintenir.
  • Cela permet d’accélérer sensiblement le rythme des livraisons.

Politique de versionning.

Vous me direz : la gestion de la compatibilité ascendante, c’est très bien, mais il arrive parfois qu’il ne soit pas souhaitable de poursuivre la compatibilité ascendante et que le code obsolète ou déprécié doive être retiré.

C’est tout à fait vrai et il faut que cela reste possible. La question qui se pose alors est comment identifier une version qui supporte la compatibilité ascendante d’une version qui ne la supporte plus.

Tout simplement en utilisant une politique de versionning claire et facilement identifiable basée sur 3 nombres:

majeur.mineur.patch

où :

Majeur, un changement nécessitant la mise à niveau du consommateur de service et de l’implémentation.

Mineur, un changement nécessitant la mise à niveau du l’implémentation, mais pas du client.

Patch, n’est  utile que pour la livraison d’implémentations, c’est à dire pour la correction de Bugs ou l’amélioration de fonctionnalité (performances).

Tests d’intégration.

Afin de garantir la compatibilité ascendante, il vous faudra également rédiger des tests d’intégrations dans un projet séparé et exécuter les tests prévus pour la version précédente sur la nouvelle version.

image

Liens et références.

Eclipse Version Numbering

Backward Compatibility (Excellent article qui m’a beaucoup aidé).

Portable Runtime Project (Apache)

Moving forward with Web services backward compatibility

Publicités

Créez un site Web ou un blog gratuitement sur WordPress.com.