esup-commons résout le problème de la cohérence entre les versions de l'application et de la base sur laquelle elle s'appuie, en particulier dans les environnements cluster de nos portails.
A quoi correspondent les numéros de version ?
Les numéros de version sont toujours de la forme x.y.z-t, maintenus dans le fichier /properties/misc/application.xml :
- x : le n° majeur de version, peut être changé en cas d'ajouts/changements de fonctionnalités importants, ou pour des refontes majeures des applications. Par convention, le changement de n° majeur peut impliquer pour l'utilisateur des manipulations manuelles pour la mise à jour, alors que toutes les autres mises à jour doivent se faire de manière (semi-) automatique.
- y : le n° mineur de version, qui correspond en général à un niveau de fonctionnalités. Pour un changement de n° mineur, l'exploitant est toujours invité à exécuter la tâche ant uprade, qui met à jour la structure de la base. C'est à cette occasion que le développeur peut faire exécuter des mises à jour supplémentaires, par exemple sur les données elles-mêmes, en allant modifier le bean versionningService.
- z : le n° de patch. Par convention, on conserve le n° de patch lorsque l'on ne modifie pas les fonctionnalités. à noter qu'une mise à jour pour un même n° de version mineur se fait de manière automatique, sans nécessiter l'appel de la tâche ant uprade.
- t : le n° de packaging, qui change seulement lorsque l'on modifie la documentation, le déploiement ou les fichiers d'exemple.
A chaque fois que l'on modifie la structure de la base, il suffit d'incrémenter le n° de version mineur : esup-commons force l'appel de ant upgrade (en lançant une exception) tant que le n° mineur de la base et celui de l'application ne sont pas les mêmes.
L'appel de la tâche upgrade, en plus de mettre à jour la structure de la base de données, peut également être l'occasion de mettre à jour des données à l'aide de code Java exécuté par le bean versionningService (défini dans /properties/init/init.xml), qui est appelé par la tâche upgrade.
Note : le bean versionningService est également appelé de manière automatique par l'application lorsque seul le n° de patch diffère. Il est donc possible également dans ce cas d'exécuter du code de mise à jour des données.
| Exercice : Créer une incompatibilité de version entre application et base | Afficher l'énoncé |
| Exercice : Mettre à jour la base de données | Afficher l'énoncé |
Comment ne pas gérer les numéros de version ?
Lorsque l'on ne s'appuie pas sur une base de données, on ne veut pas avoir à gérer les problèmes de cohérence du numéro de version entre application et base de données.
Il suffit alors de s'appuyer sur un bean versionningService ne faisant rien du tout, par exemple en le déclarant de la classe VoidVersionningServiceImpl.
Comment faciliter les mises à jour ?
Distribuer une mise à jour d'un logiciel est en général chose facile, d'autant plus avec esup-commons car il suffit d'appeler une tâche ant.
La mise à jour sur une plateforme de production est en général beaucoup plus délicate à cause de la nécessité de maintenir la cohérence des numéros de version de l'application et de la base de données. Ce point est résolu par le bean versionningService, comme montré plus haut. Elle est également fastidieuse, car tous les fichiers de configuration doivent être recopiés depuis l'installation antérieure.
Ce dernier problème est résolu à l'aide la tâche ant recover-config, qui récupère automatiquement les anciens fichiers de configuration et les installe dans la nouvelle instance de l'application. Nous décrivons dans cette partie comment fonctionne la tâche recover-config, et ce que doit faire le développeur pour qu'elle fonctionne correctement.
Comment la tâche recover-config fonctionne-t-elle ?
Toutes les versions de l'application sont sensées être installées au même niveau sur le système de fichiers, ce qui fait que l'application sait qu'elle doit rechercher dans le répertoire immédiatement supérieur (../).
La propriété ${recover.previous-versions} est une liste de versions (séparées par des virgules), dont la tâche recover-config va chercher la présence automatiquement. Dans la pratique, pour chaque numéro de version x.y.z, la tâche recherche les répertoires ../application-x.y.z et ../application-quick-start-x.y.z.
Une fois le répertoire trouvé, la tâche récupère les fichiers indiqués par la propriété ${recover.files} et les recopie dans la nouvelle instance de l'application.
Comment un développeur fait-il fonctionner la tâche recover-config ?
Le développeur doit tout d'abord mettre à jour la propriété ${recover.previous-versions} à chaque fois qu'il incrémente le n° de version de l'application, sans quoi les versions non indiquées par la propriétés ne seront pas prises en compte.
Il doit ensuite indiquer quels sont les fichiers qui doivent être récupérés par la tâche.
Comme dit plus haut, les fichiers de configuration à récupérer sont donnés par la propriété ${recover.files}, qui elle même construite à partir de ${commons.recover.files} et ${app.recover.files}. Le développeur doit donc indiquer quels sont les fichiers de configuration de l'application qu'il souhaite récupérer automatiquement à l'aide de ${app.recover.files}, à configurer dans le fichier build.xml. On trouvera par exemple :
<property name="app.recover.files" value=" properties/init/init.xml properties/domain/domain.xml properties/i18n/bundles/NetworkAppliance_*.properties properties/i18n/bundles/Custom_*.properties " />
Comment un administrateur utilise-t-il la tâche recover-config ?
Il suffit d'installer la nouvelle version au même niveau que la précédente sur le système de fichiers ; c'est un prérequis. L'exécution de la tâche recover-config suffit ensuite pour récupérer les fichiers de configuration automatiquement (le numéro de l'ancienne version est détectée automatiquement).
Pour récupérer d'autres fichiers que ceux explicitement prévus par le développeur, il suffit de spécifier ces fichiers dans la propriété ${custom.recover.files}, par exemple :
custom.recover.files=\ webapp/media/enabled.jpg \ properties/applicationContext.xml \ properties/local/local.xml \ src/edu/domain/application/domain/*.java