Contrôle des règles de mise à jour Eclipse

La mise à jour Eclipse permet aux utilisateurs de rechercher des mises à jour des dispositifs installés. Pour chaque dispositif installé, la mise à jour utilise l'URL intégrée pour se connecter au serveur éloigné et rechercher de nouvelles versions. Si des mises à jour existent, Eclipse permet aux utilisateurs de lancer la procédure d'installation. Après le téléchargement, l'installation et le redémarrage de la plateforme, la nouvelle version de dispositif est prête à l'emploi.

Dans les sociétés qui comprennent de nombreux utilisateurs du même produit Eclipse (en général, un produit commercial), plusieurs incidents peuvent se produire à partir de ce modèle :

  1. Les mises à jour des produits de très grande taille (par exemple, plug-in de plus de 500 Mo) sont également volumineuses. Le service d'assistance informatique ne souhaite peut-être pas que des centaines de développeurs téléchargent individuellement des mises à jour de 500 Mo sur leurs machines. Outre l'accès à la largeur de bande, une demande de téléchargement de ce type risque d'échouer, ce qui donne lieu à des tentatives renouvelées et à une augmentation de la durée d'immobilisation des développeurs.
  2. Certaines sociétés ne souhaitent explicitement pas que les développeurs téléchargent des mises à jour directement sur Internet. Par exemple, elles peuvent mettre en place une équipe d'assistance locale qui risque de ne peut pas être prête à traiter les demandes liées à la version du produit qui est déjà disponible sur le site de mise à jour du fournisseur. Elles peuvent être amenées à limiter les mises à jour et les correctifs à la liste approuvée en interne. L'idéal serait qu'elles procèdent à cette restriction en configurant des sites de mise à jour 'proxy' sur le réseau local (à l'arrière du pare-feu).
  3. Une fois que les mises à jour sont définies dans les sites proxy comme indiqué ci-dessus, les administrateurs nécessitent une méthode pour informer les utilisateurs que les mises à jour sont disponibles.

2. Règles de mise à jour à la rescousse

2.1 Support de création de sites de mise à jour locales (proxy)

La première étape destinée à un administrateur de produit consiste à configurer un site de mise à jour Eclipse local sur un serveur connecté au réseau local de la société (derrière le pare-feu). Le site de mise à jour correspond à un sous-ensemble du site de mise à jour du produit sur Internet car il ne contient que les dispositifs et plug-in liés aux mises à jour que la société souhaite appliquer pour le moment. En termes techniques, il s'agit d'un site de mise à jour Eclipse classique comportant des archives de fichier site.xml, de dispositif et de plug-in.

Les administrateurs construisent ce site selon les deux méthodes suivantes :

  1. A cet effet, les équipes de support produit mettent à disposition un fichier zip du site de mise à jour. Il suffit aux administrateurs de télécharger le fichier zip à partir de la page Web de support produit à l'aide de l'outil de leur choix et de le dézipper sur le serveur local. Cette méthode est utile pour les fichiers zip de très grande taille qui requièrent des gestionnaires de téléchargement réamorçables modernes (ceux qui peuvent être rétablis dans le cas des incidents de connexion).
  2. La mise à jour Eclipse propose un outil pour effectuer la fonction miroir au niveau des sites de mise à jour éloignés ou permettre aux administrateurs de sélectionner des mises à jour et des correctifs à télécharger. Cette fonction miroir est entièrement automatisée et simplifie considérablement la tâche de l'administrateur ; cependant, elle repose sur le support de mise à jour de la connexion réseau.

2.2 Contrôle des règles de mise à jour courantes

Dans la mesure où les dispositifs sont dotés de l'URL de site de mise à jour qui est intégrée dans le manifeste, ils ne sont pas au courant des sites de mise à jour locaux configurés par les administrateurs. Il est donc important de fournir la fonction de réacheminement. Vous pouvez définir ces paramètres de règles de mise à jour ainsi que d'autres en créant un fichier de règles de mise à jour et en configurant la fonction de mise à jour de sorte qu'elle utilise ce fichier lors de la recherche.

Le fichier en question utilise le format XML et peut porter n'importe quel nom. Il peut être défini dans Préférences>Installation/Mise à jour dans la zone Règles de mise à jour. La zone de texte est vide par défaut : les utilisateurs peuvent définir l'URL du fichier de règles de mise à jour. Le fichier est géré par l'administrateur local et est partagé pour toutes les installations de produit. Le partage peut s'effectuer des deux manières suivantes :

Le fichier de règles doit être conforme à la définition de type de document (DTD) suivante :

<?xml encoding="ISO-8859-1"?>

<!ELEMENT update-policy (url-map)*>
<!ATTLIST update-policy
>

<!ELEMENT url-map EMPTY>
<!ATTLIST url-map
    modèle    CDATA #REQUIRED
    url        CDATA #REQUIRED
>

url-map

Cet élément sert à remplacer les URL de mise à jour intégrées dans les manifestes de dispositif. Lors de la recherche de nouvelles mises à jour, Eclipse contrôle les règles de mise à jour (s'il y a lieu) et vérifie si url-map correspondant au préfixe de dispositif correspondant est indiqué. Si une occurrence est détectée, l'URL mappée est utilisée à la place de celle qui est intégrée. De cette manière, les administrateurs peuvent configurer les produits Eclipse de sorte que ces derniers recherchent des mises à jour sur le serveur local derrière le pare-feu. Entre-temps, les dispositifs tiers installés par le fonction de mise à jour Eclipse continuent d'être mis à jour à l'aide de la méthode par défaut, car ils ne trouvent pas d'occurrence dans les règles.

Il se peut que le fichier contienne plusieurs éléments url-map. Les préfixes de dispositif peuvent être choisis de sorte qu'ils soient plus ou moins spécifiques. Par exemple, pour réacheminer toutes les mises à jour Eclipse, l'attribut de modèle serait "org.eclipse". De même, il est possible d'utiliser un ID dispositif complet sous forme de modèle, si le réacheminement est requis pour chaque dispositif.

Les modèles figurant dans le fichier peuvent être choisis de manière à restreindre progressivement les éventuelles occurrences. Il peut en résulter plusieurs occurrences pour un dispositif donné. Dans ce cas, l'occurrence comportant le modèle le plus long va être utilisée. Par exemple :

<?xml version="1.0" encoding="UTF-8" ?>
<update-policy>
	<url-map pattern="org.eclipse" url="URL1"/>
	<url-map pattern="org.eclipse.jdt" url="URL2"/>
</update-policy>

Dans le cas ci-dessus, tous les dispositifs Eclipse sont mis à jour à partir d'URL1, à l'exception de org.eclipse.jdt qui utilise URL2.

Les fichiers de règles de mise à jour ne contiennent pas de chaînes convertissables et, par conséquent, ne requièrent pas un traitement NL spécial. En général, les fichiers doivent utiliser le codage UTF-8.

2.3 Découverte automatique des mises à jour

La troisième partie de la solution globale est décrite dans une autre rubrique, mais elle est mentionnée dans la présente section car elle fait partie intégrante de la solution. Les mises à jour automatiques permettent à Eclipse d'exécuter une recherche de mise à jour selon un calendrier spécifié (à chaque démarrage (par défaut), une fois par jour, une fois par semaine, etc.).

3. Récapitulatif

Voici la séquence complète des étapes qui composent la solution :

  1. L'administrateur affecte un serveur sur le réseau local de la société pour l'hébergement des mises à jour de produit locales. A l'origine, ce serveur ne contient pas de sites de mise à jour. Un serveur HTTP doit être en cours d'exécution sur la machine.
  2. L'administrateur configure un fichier de règles de mise à jour sur ce serveur et demande à tous les utilisateurs de définir la préférence de règles de mise à jour à l'aide de l'URL fournie.
  3. Lorsque le fournisseur du produit livre les mises à jour et les correctifs sur les sites de mise à jour, l'administrateur télécharge sur le serveur local les mises à jour prises en charge.
  4. La mise à jour automatique exécutée selon la fréquence planifiée lorsque le produit du client est actif extrait les mises à jour locales et notifie l'utilisateur.
  5. L'utilisateur choisit d'installer les mises à jour découvertes.

Tâches connexes
Planificateur de mises à jour automatique