Packaging (2/2)

fichier et ne demandent au Transmitter que les octets modifiés. Dès que les octets arrivent sur un Tuner, celui-ci incorpore les modifications et met à  jour le fichier original sur son disque dur. Pour les fichiers verrouillés, le Tuner copie l’original, met à  jour la copie avec les modifications au niveau octet, puis remplace (par écrasement) l’original lors de la réinitialisation. L’économie en bande passante de réseau peut être appréciable pour de grands fichiers subissant de petites modifications, et le processus n’engendre pas plus de charge de processeur pour le client qu’un écrasement de fichier ordinaire.

   TS.Ready utilise des contrôles de redondance cycliques (CRC, cyclical redundancy checks) pour s’assurer de l’intégrité de ses fichiers packagés. Tout comme MD5, les CRC analysent finalement l’état d’une application. Quand un fichier est corrompu ou manquant, le client peut demander un remplacement à  partir d’un lieu désigné, pour réparer l’application. Comme MD5 aussi, les CRC permettent des changements de version rétroactifs (rollbacks), ainsi que des patches et des mises à  niveau incrémentiels permettant de n’envoyer et de n’installer que les fichiers modifiés plutôt que toute l’application.

   L’utilitaire de packaging de WinINSTALL possède quelques caractéristiques uniques très intéressantes dans certains environnements. Outre la possession d’une interface souple pour modifier les packages après les avoir créés, WinINSTALL permet de convertir un package Installer de WinINSTALL au format .msi. Cette dernière fonction peut s’avérer utile, par exemple, dans un environnement AD dans lequel on utilise Group Policy pour déployer un logiciel vers les clients Win2K, tout en ayant encore besoin d’un outil de déploiement fiable pour les anciens clients Windows. Le WIPL (WinINSTALL Program Launcher) permet de faire connaître les applications de la même manière que dans un environnement AD. Depuis la console administrative de WinINSTALL, on peut attribuer une application aux utilisateurs, et le produit place une icône d’application sur leur bureau. Pour lancer WIPL et installer le package, l’utilisateur fait un double clic sur l’icône.

   Les fonctions de packaging d’eXpress sont simples mais souples. On peut personnaliser une installation, mais le package résultant est un fichier exécutable. On peut donc déployer le package à  son gré (par exemple, le placer dans un répertoire partagé, l’envoyer en attachement de courrier électronique, le mettre à  disposition sur un site FTP, l’enregistrer sur une disquette de 3,5 » ou un CD-ROM) et – si des autorisations administratives ne sont pas nécessaires – sur des clients ne disposant pas du logiciel client eXpress. Il est intéressant de n’avoir qu’un fichier exécutable par application, parce qu’ainsi on peut créer un CD-ROM avec une collection d’applications dans le cadre d’un kit d’urgence pour utilisateurs itinérants. Le seul inconvénient du processus de packaging eXpress est l’incapacité de modifier le chemin d’installation (install path) une fois qu’on a créé un package – eXpress ne permet pas d’utiliser des variables d’environnement à  la place d’une instruction de chemin (path) fixe. De plus, bien qu’eXpress donne le moyen de créer une routine de désinstallation pour chaque package Install, je n’ai pas pu trouver une fonction rétroactive pour les installations ratées.

   La fonction packaging englobe la création des packages mais aussi leur installation. J’ai constaté que les cinq produits testés présentaient différents niveaux de fonctionnalité dans le domaine de l’installation, bien que tous remplissent parfaitement leur rôle. Comme j’ai choisi de déployer le Microsoft Office 2000 Professional de 500 Mo comme application test, le défi pour les produits était davantage lié au déploiement d’une application aussi vaste qu’à  la création d’un package pour elle. J’ai été impressionné par l’utilisation des algorithmes de compression gzip par NETDEPLOY GLOBAL, qui ont réduit le package Office 2000 à  319 Mo.

   eXpress permet d’aborder une installation .msi de façon très élémentaire : on utilise la console administrative pour créer un événement qui copie le fichier .msi sur le client et exécute localement msiexec.exe avec les paramètres de ligne de commande désirés. Outre l’avantage de la planification (scheduling), eXpress n’offre pas beaucoup plus qu’AD en matière d’attribution du logiciel. La solution de WinINSTALL était semblable, à  cela près qu’elle a pu exploiter l’API Windows Installer et fournir une entrée de réussite ou d’échec dans le journal des événements.

   Les trois autres produits offrent davantage de fonctions intégrées concernant les packages .msi, comme la possibilité de concevoir des transformations et celle d’ajouter des chemins pour les fichiers source .msi afin que les fonctions de réparation et d’installation à  la demande opèrent quel que soit l’emplacement du client. Castanet et NETDEPLOY GLOBAL permettent également de préciser ce que l’on veut installer sur le client et si celui-ci doit conserver ce que l’on installe. Dans le cas d’Office 2000, j’ai pu choisir de télécharger le package .msi seulement, le fichier .msi et tous les fichiers source, ou le fichier .msi et seulement les fichiers nécessaires. Si l’espace sur le disque dur est abondant, on peut conserver les fichiers source sur le client et désigner ce répertoire comme le chemin du fichier source. Avec les fichiers source d’une application disponible localement, un client déconnecté pourrait installer à  la demande ou autocorriger l’application.