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

3 commentaires »

  1. Super article qui mérite d’être relayé !

    Le schéma est très parlant et nous avons déjà échangé à ce sujet récemment, mais je pense que la définition de la compatibilité ascendante doit être détaillée pour qu’elle soit bien assimilée de tous. Est-ce simplement rester compatible avec les versions antérieures de l’application ?

    Si je veux garder la compatibilité ascendante et dans le même temps transformer ma relation Client-Adresse en une relation où le client possède plusieurs adresses. Comment gérer ce cas d’utilisation ?

    Un bon article qui traite de manière « particulière » la compatibilité ascendante :
    http://www.jroller.com/eu/entry/dealing_with_api_compatibility

    Commentaire par Cyril Lakech — 01/03/2010 @ 9:49 | Répondre

  2. Bonjour Cyril et merci pour tes remarques,

    La compatibilité ascendante doit partir du point de vue du consommateur de service : il doit pouvoir monter de version sereinement sans craindre pour ses applicatifs déjà déployés. Cette approche est fondamentale dès que l’on commence à faire de l’intégration.

    Dans la relation initiale Client-Adresse, il faut continuer à fournir l’adresse attendue par exemple l’adresse principale du client. Éventuellement, tu peux déprécier les accesseurs et les remplacer par des accesseurs qui qualifient mieux l’attribut (Ex : « getAddressePrincipale »), l’attribut sous-jacent restant le même.

    Dans tous les cas, si le getAddress/setAddress ne fournit plus le résultat attendu, tu doit changer de version majeure.

    Commentaire par pascalleclercq — 01/03/2010 @ 10:18 | Répondre

  3. Bonjour,

    il peut être intéressant de valider automatiquement la compatibilité ascendante entre 2 versions de librairies. https://github.com/jeluard/semantic-versioning permet cela via un plugin maven.

    Julien

    Commentaire par Julien — 22/03/2011 @ 12:09 | Répondre


RSS feed for comments on this post. TrackBack URI

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Propulsé par WordPress.com.

%d blogueurs aiment cette page :