II. Différentes méthodes possibles▲
La mise à jour permet à l'utilisateur d'obtenir la dernière version du logiciel lorsqu'il possède une version antérieure. Il existe plusieurs méthodes de mises à jour, je vais donc vous en présenter quelques-unes. D'autres méthodes sont sûrement envisageables, mais nous ne les aborderons pas ici.
II-A. Désinstallation puis installation▲
Une désinstallation suivie d'une installation est certainement la méthode la plus simple.
Pour peu que vous utilisiez un programme spécifique pour l'installation (setup.exe) et un programme spécifique pour la désinstallation (uninstall.exe) votre gestionnaire de MàJ ne sera composé que d'un appel à uninstall.exe suivi d'un téléchargement de ressources (si le setup.exe ne le fait pas lui-même) et enfin d'un appel à setup.exe.
Mais il est inutile et coûteux de supprimer et de retélécharger les fichiers qui n'auraient pas été modifiés. Imaginez que votre projet soit assez volumineux (plus de 600 Mo) et que la mise à jour ne porte que sur un petit fichier de quatre ko…
Simplicité | Flexibilité | Flux | Temps | MàJ hors ligne |
II-B. Un exécutable pour chaque MàJ▲
Une autre méthode consiste à faire télécharger par le client un exécutable spécifique à chaque MàJ qui se chargera d'actualiser le logiciel. Le rôle du gestionnaire de mises à jour sera donc de télécharger cet exécutable puis de l'exécuter.
Les ressources nécessaires pourront soit être téléchargées par le gestionnaire de mises à jour en même temps que l'exécutable, soit être téléchargées par celui-ci.
Rien n'empêche de télécharger certaines ressources par la première méthode et les autres par la seconde.
Souvent quelle que soit la version, on téléchargera le même exécutable, ce sera donc à lui, en fonction de la version du client d'exécuter la séquence d'instructions correspondantes.
Pour plus d'efficacité, on peut faire télécharger le même exécutable pour un « groupe de versions » voire pour chacune des versions.
Nous pouvons remarquer que les exécutables téléchargés pour les différentes MàJ contiendront tous une base commune et qu'à chaque MàJ, nous retéléchargerons cette base.
Simplicité | Flexibilité | Flux | Temps | MàJ hors ligne |
La MàJ hors ligne est possible mais elle est incompatible avec une bonne flexibilité face aux modifications apportées par l'utilisateur.
II-C. Archive contenant tous les éléments▲
L'un des problèmes de la méthode précédente est le téléchargement d'un exécutable très similaire d'une mise à jour sur l'autre.
Nous pouvons donc intégrer au gestionnaire de mises à jour la base commune à tous ces exécutables et remplacer l'exécutable par un simple fichier contenant toutes les instructions à effectuer. Le gestionnaire devra donc interpréter les instructions (principalement : déplacements et suppressions) et les exécuter.
Le téléchargement ne pourra donc plus se faire via l'exécutable, les ressources seront donc téléchargées en même temps que le fichier contenant les instructions.
Afin de limiter le travail du serveur, on peut préparer des archives, afin de limiter le nombre d'archives, nous pouvons aussi ne faire qu'une archive pour un groupe de versions.
Simplicité | Flexibilité | Flux | Temps | MàJ hors ligne |
II-D. Méthode Diff et Patch▲
Cette méthode utilise très peu de bande passante.
Au lieu de remplacer entièrement un fichier lorsqu'une modification a été faite sur celui-ci, on va regarder les octets qui ont changé entre deux fichiers de versions (commande diff sous Linux).
Le client va donc télécharger le fichier produit puis ne va changer que les octets qui ont été modifiés (commande patch sous Linux).
En cas de modification du fichier par l'utilisateur, la mise à jour ne sera pas correcte.
Il est possible de comparer le fichier du client au fichier attendu (avec un hash par exemple).
Et dans le cas où il aurait été modifié, il faudra soit recomparer les deux fichiers, soit retélécharger l'original.
Simplicité | Flexibilité | Flux | Temps | MàJ hors ligne |
II-E. Détermination des ''modifications'' côté client▲
Cette méthode consiste à envoyer toutes les informations nécessaires sur la nouvelle MàJ au client. C'est-à-dire envoyer au minimum l'arborescence, les liens de téléchargement des fichiers ainsi qu'un moyen de comparer les versions des fichiers :
- comparer les contenus des fichiers : on doit alors télécharger la dernière version du fichier, à ce niveau-là, la méthode d'installation-désinstallation est tout aussi efficace ;
- comparer les hash des différents fichiers ce qui permet une bonne flexibilité ;
- avoir côté client un fichier contenant la version de chaque fichier. Mais il ne correspondra pas forcément à la réalité car à chaque modification ou suppression de fichier du logiciel par l'utilisateur, il ne sera pas mis à jour.
Le gestionnaire de MàJ devra donc, en fonction des fichiers présents du côté du client déterminer toutes les instructions ainsi que les fichiers à télécharger pour effectuer la mise à jour.
L'un des avantages de cette méthode est de pouvoir mettre à jour des versions non officielles (non reconnues par le serveur).
Simplicité | Flexibilité | Flux | Temps | MàJ hors ligne |
II-F. Mises à jour successives▲
Cette méthode est très utile si on souhaite conserver toutes (ou certaines) les (des) versions du logiciel.
On considère qu'on ne sait que passer de la version X à la version X+1, on va donc enchaîner les mises à jour jusqu'à ce qu'on atteigne la dernière version.
N.B. On peut aussi faire des mises à jour par paliers, c'est-à-dire que pour chaque version on sait comment obtenir une version palier plus récente. Et à partir de cette version palier, on peut obtenir une autre version palier encore plus récente jusqu'à obtenir la dernière version.
Mais si un fichier a été modifié cinq fois entre la dernière version et la version X, il faudra le télécharger cinq fois. Si on souhaite conserver toutes les versions du logiciel, il faudra gérer différentes versions côté serveur afin de pouvoir télécharger d'anciennes versions de fichiers.
Simplicité | Flexibilité | Flux | Temps | MàJ hors ligne |
II-G. Mise à jour unique▲
Le client envoie sa version (X) au serveur qui lui retourne une liste d'instructions permettant de passer de la version X à la version Y.
Le gestionnaire va donc exécuter ces instructions et va télécharger uniquement les fichiers dont il a besoin, soit un par un, soit en demandant au serveur de préparer une archive avec tous les fichiers nécessaires.
Dans cette méthode, il est nécessaire de pouvoir déterminer à chaque version, les instructions exactes à effectuer. Bien sûr, il ne faudra pas écrire toutes ces instructions à la main, nous allons donc devoir essayer d'automatiser la génération des instructions nécessaires.
Grâce à cette méthode, il sera donc possible de revenir à une version antérieure très facilement soit par souhait du développeur soit par souhait du client (nécessite alors une gestion des versions des fichiers côté serveur).
C'est la méthode qu'on détaillera par la suite.
Simplicité | Flexibilité | Flux | Temps | MàJ hors ligne |
II-H. Résumé des méthodes▲
désinstallation-installation | exécutable | Archive | Diff & Patch | Détermination côté client |
MàJ successives |
MàJ unique | |
Simplicité | |||||||
Flexibilité | |||||||
Flux | |||||||
Temps | |||||||
MàJ hors ligne |
Ce tableau a pour but d'essayer de récapituler les points forts et les points faibles de chaque méthode, mais il convient de choisir une méthode selon vos propres besoins, limitations et objectifs.