Mises à jour Mercator : une stratégie de versioning qui respecte votre investissement

Depuis la version 1.0 de Mercator, l’objectif de l’équipe de développement a toujours été d’assurer une transition fluide entre les différentes versions, sans rupture brutale pour les utilisateurs.
Il nous parait impensable que nos clients perdent leur investissement au gré des mises à jour de Mercator ou éprouvent des difficultés liées à celles-ci. Alors, comment procédons-nous ? 

La stratégie de versioning – gestion des versions

L’évolution du logiciel Mercator est quotidienne. Nous ne cessons jamais d’ajouter des fonctionnalités et d’en modifier d’autres. Les fonctionnalités liées à une version sont distillées au fur et mesure. La stratégie est donc celle d’une pente douce.

Ce mode de distribution permanente offre de nombreux avantages :
Il n’est pas nécessaire d’attendre un changement de version pour obtenir, en une seule fois, un lot conséquent de fonctionnalités. Elles arrivent dès qu’elles sont prêtes.
Dès lors, il n’y a jamais de grosse rupture entre les versions. Cela réduit le risque de bugs lors de la mise à jour.

Même si des fonctionnalités majeures sont libérées à partir d’une certaine version, l’équipe de développement travaille toujours sur un seul exécutable.
L’avantage pour les utilisateurs est qu’il n’est pas nécessaire d’attendre la version suivante pour qu’un bug soit corrigé. Les correctifs sont déployés gratuitement dans l’unique exécutable utilisé par tous nos clients. La modification / correction à un seul endroit rend le développement plus efficace et donc plus rapide : la plupart du temps, en quelques heures ou dans la journée. 

Mercator évolue mais la compatibilité ascendante est assurée

Fréquemment, de nouvelles options sont ajoutées dans le standard de Mercator pour répondre à des besoins métiers supplémentaires.

Lors de l’ajout d’une option, l’équipe de développement veille à ce que la valeur par défaut de celle-ci corresponde au comportement qui prévalait avant la mise à jour. Ainsi : 

• L’utilisateur qui n’est pas concerné par cette option n’a aucune action à réaliser et continue d’utiliser son ERP à l’identique. 
• Et l’utilisateur qui attend cette nouvelle fonctionnalité peut simplement l’activer selon son choix.

Les personnalisations de chaque client sont maintenues, à chaque mise à jour

Mercator ERP n’est pas un programme « open source ». Et c’est un avantage pour nos utilisateurs.

Dans un ERP « open-source », les modifications de comportement du logiciel et l’ajout de fonctionnalités sont effectuées directement dans le code de l’application. Ces modifications seront perdues lors de l’installation d’une mise à jour. 
Pour pallier à ça, les développeurs adoptent une stratégie modulaire : le code sur-mesure est placé dans des modules séparés qui ne seront pas nécessairement affectés par une mise à jour. 
Certes, c’est mieux. Mais il restera toujours un travail à faire : s’assurer que ces modules séparés peuvent être « rebranchés » sur la nouvelle version du cœur. Cela implique des migrations et du testing, à chaque mise à jour. Et donc un coût non négligeable, voire même une indisponibilité de certaines fonctionnalités, le temps de les retravailler.

Dans Mercator, cette stratégie modulaire est prévue depuis la 1^ière ligne de code. Les modules sur-mesure s’imbriquent sur des points d’appels qui, eux, ne seront jamais modifiés. En d’autres termes, une mise à jour du cœur de l’application n’impactera jamais les points de branchement des modules. 
On compte plusieurs milliers de points de branchement entre le cœur et le code sur-mesure. 
Pour les plus techniques de nos lecteurs, ces points sont définis dans des interfaces publiques ou des événements publics. La plateforme .net met à disposition le nécessaire pour bien séparer ces deux réalités. L’équipe de développement veille à ce que, au gré des versions, ce qui est « public » (au sens de la programmation objet) reste inchangé. Le framework .net contient tout ce qu’il faut pour enrichir l’API de Mercator sans jamais briser la rétrocompatibilité :

• Ajout de signatures sur les méthodes existantes afin d’augmenter le nombre de paramètre passés.
• Ajout de propriétés publiques dans les classes publiques de Mercator.

Cette architecture native du logiciel permet donc d’assurer une compatibilité ascendante, même en ce qui concerne les développements sur-mesure.

La base de données s’adapte automatiquement, au gré des version

Nul besoin de scripts de migration de données lors d’une mise à jour de Mercator. Lors de son démarrage, le logiciel veille à ajouter les nouvelles colonnes ou ressources sur la base de données. Si nécessaire, les fonctions, procédures stockées et déclencheurs sont automatiquement mis à jour.
Lors de l'ajout d'un module standard au dossier, les nouvelles tables sont aussi automatiquement ajoutées à Mercator. 

Ces opérations sont totalement invisibles pour l’utilisateur.

Les mises à jour se déroulent sans impact

La plupart des utilisateurs Mercator bénéficient d’une mise à jour automatique effectuée la nuit. Les mises à jour de Mercator peuvent même être effectuées « à chaud », c’est-à-dire sans contraindre tous les utilisateurs à quitter le programme. 

Que ça soit pour l’installation d’une mise à jour mineure ou majeure, le processus de mise à jour de Mercator est routinier, simple et même anodin. 

En résumé, Mercator propose un modèle de mises à jour fluide, sans rupture et sans contrainte pour les utilisateurs. L’objectif est de garantir un logiciel toujours performant, à jour mais également de protéger l’investissement de nos clients : la personnalisation de leur logiciel doit être sauvegardée.