Comment dois-je implémenter un programme de mise à jour automatique?
De nombreux programmes incluent un programme de mise à jour automatique, dans lequel le programme recherche occasionnellement des mises à jour en ligne, puis télécharge et applique les mises à jour trouvées. Les bogues du programme sont corrigés, les fichiers de support sont modifiés et les choses sont (généralement) améliorées.
Malheureusement, peu importe les efforts que je fais, je ne peux trouver aucune information sur ce processus. Il semble que les programmes de mise à jour automatique mis en œuvre aient été propriétaires ou considérés comme non importants.
Il semble assez facile d'implémenter le système qui recherche les mises à jour sur un réseau et les télécharge si elles sont disponibles. Cette partie de la mise à jour automatique changera considérablement d'une mise en œuvre à l'autre. La question est de savoir quelles sont les différentes approches de application correctifs. Juste en téléchargeant des fichiers et en remplaçant les anciens par de nouveaux, en exécutant un script de migration qui a été téléchargé, en réparant des parties du système, etc.? Les concepts sont préférés, mais des exemples en Java, C, Python, Ruby, LISP, etc. seraient appréciés.
Je pense que le "langage agnostique" va être un facteur limitant ici. Les applications ont tellement de formes et de tailles qu’il n’ya pas de solution unique. J'ai implémenté plusieurs programmes de mise à jour automatique dans plusieurs langues, et aucune n'est similaire.
La philosophie la plus générale est que l’application vérifie auprès de certains lieux de résidence (adresse Web, requête Web, emplacement du réseau d’entreprise, etc.) pour demander si sa version est actuelle ou quelle est la version la plus récente. Si la réponse appelle une mise à jour, ce processus sera différent pour chaque situation.
Une alternative populaire consiste à inviter l’emplacement personnel à exécuter un script lors du lancement de l’application. Le script peut vérifier la version, télécharger des mises à jour si nécessaire et demander des informations sur l'utilisation, par exemple.
Nous pouvons probablement mieux vous aider si vous réduisez les paramètres.
MISE À JOUR: L'approche de "correction" dépend également de la nature de l'application, et la diversité est très grande ici. Si vous avez un seul fichier exécutable, par exemple, il est probablement plus pratique de remplacer l'exécutable. Si votre application contient plusieurs fichiers, vous devez rechercher des moyens de réduire le nombre de fichiers remplacés. Si votre application est hautement personnalisée ou paramétrée, vous devez vous efforcer de minimiser les efforts de reconfiguration. Si votre application utilise du code interprété (telle qu'une application VBA Excel ou une application MS Access MDB), vous pourrez peut-être remplacer certaines parties du code. Dans une application Java, il suffit parfois de remplacer un fichier JAR, voire un sous-ensemble du contenu du fichier JAR. Vous aurez également besoin d'un moyen de reconnaître la version actuelle du client et de la mettre à jour correctement. Je pourrais continuer encore et encore, mais j'espère que vous voyez ce que je veux dire à propos de la diversité. C’est l’une de ces nombreuses fois où la meilleure réponse commence habituellement par «Eh bien, ça dépend…! C'est pourquoi tant de réponses incluent "Veuillez affiner les paramètres".
Veillez également à prendre en compte les implications en termes de sécurité de la récupération des informations relatives à la mise à jour, ainsi que les fichiers binaires de la mise à jour eux-mêmes.
Avez-vous confiance en la source du téléchargement? Vous téléphonez peut-être à la maison pour obtenir votre mise à jour, mais que se passe-t-il s'il y a un homme au milieu qui redirige vers un serveur malveillant? Une connexion sécurisée HTTPS ou similaire peut aider, mais il est recommandé de vérifier les bits que vous avez éventuellement téléchargés à l'aide d'une vérification de signature numérique.
Tout d’abord, vous avez besoin d’un fichier sur le site Web d’accueil de votre application avec la version la plus récente. Le meilleur moyen d’avoir un tableau SQL spécial pour cette tâche et de le remplir automatiquement après la publication de la nouvelle version/l’achèvement de la construction nocturne ... crée un nouveau fil qui demande un lien http intégré à la version et se compare au courant. En .Net Use peut utiliser un code comme celui-ci:
Version GetLatestVersion() {
HttpWebRequestrequest = (HttpWebRequest)WebRequest.Create(new Uri(new Uri(http://example.net), "version.txt));
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
if (request.HaveResponse)
{
StreamReader stream = new StreamReader(response.GetResponseStream(), Encoding.Default);
return new Version(stream.ReadLine());
}
else
{
return null;
}
}
Version latest = GetLatestVersion();
Version current = new Version(Application.ProductVersion);
if (current < latest)
{
// you need an update
}
else
{
// you are up-to-date
}
Dans cet exemple, version.php ne contient qu'une seule chaîne, telle que 1.0.1.0.
Une autre astuce que je peux donner - comment télécharger une mise à jour . L’idée suivante me plait beaucoup: dans les ressources de votre application, il existe une chaîne de code CLR que vous compilez à la volée (avec CodeDom) en un dossier temporaire, l’application principale l’appelle et se ferme. Updater lit les arguments, les paramètres ou le registre et télécharge les nouveaux modules. Et appelle l'application principale qui supprime tous les fichiers temporaires. Terminé!
(Mais tout ici concerne .NET)
Les solutions les plus simples (utilisées par de nombreux programmes) exécutent le programme de désinstallation de la version précédente et le programme d’installation du nouveau (éventuellement, en ignorant les questions auxquelles l’utilisateur a déjà répondu, comme le CLUF). Le seul problème est que la nouvelle version doit pouvoir lire les options de configuration de l'ancienne version.
De plus, sous Windows, vous ne pouvez pas supprimer un fichier exécutable en cours d'utilisation. Par conséquent, vous voudrez probablement supprimer un petit exécutable dans le dossier Temp, qui exécute l'ensemble du processus, puis le supprime à la fin de l'instance de la nouvelle version. qui a été lancé (ou juste enregistrez-le pour le supprimer au prochain redémarrage ).
Ce n'est pas vraiment une réponse complète, mais plutôt un exemple de mécanisme de mise à jour automatique que j'ai récemment mis en place. La situation est un peu différente de la tradition des applications utilisateur de type Firefox, car c’était un outil interne utilisé au travail.
Fondamentalement, il s’agit d’un petit script qui gère une file de branches Subversion à construire et à emballer dans un programme d’installation. Il lit un petit fichier où les noms des branches sont écrits, prend le premier, le réécrit à la fin du fichier et lance le processus de construction, qui implique l’appel de plusieurs scripts. La configuration de chaque branche à construire est écrite dans un fichier .INI, stocké dans un référentiel Subversion avec l'outil lui-même.
Cet outil fonctionnant sur plusieurs ordinateurs, je voulais un moyen de le mettre à jour automatiquement sur tous les ordinateurs dès que je modifiais l'outil lui-même ou les scripts de configuration.
La façon dont j'ai implémenté le processus était simple: lorsque je lance l'outil, il devient un "shell extérieur". Cette coque extérieure fait 2 choses très simples:
svn updatesur lui-même et sur les fichiers de configuration- se relance, cette fois en tant que "shell interne", celui qui gère réellement une configuration (puis se ferme à nouveau).
Ce système très simple de mise à jour moi-même dans une boucle nous a très bien servis depuis quelques mois maintenant. C'est très élégant, car il est autonome: le programme de mise à jour automatique est le programme lui-même. Parce que "shell externe" (la partie de mise à jour automatique) est si simple, peu importe qu'il ne bénéficie pas des mises à jour en tant que "shell interne" (qui est exécuté à chaque fois depuis le fichier source mis à jour).
Une chose qui n'a pas vraiment été mentionnée est que vous devriez sérieusement considérer que l'utilisateur qui exécute votre programme n'a peut-être pas suffisamment de privilèges pour le mettre à jour. Cela devrait être assez commun au moins pour les utilisateurs professionnels, probablement moins pour les utilisateurs à domicile.
Je travaille toujours avec un compte limité (auto-imposé) pour des raisons de sécurité et cela me fait toujours chier que la plupart des auto-programmes de mise à jour se contentent de supposer que je me lance en tant qu'administrateur puis que, après le téléchargement, tout échoue et n'offre aucun autre moyen d'exécution. mise à jour autre que la fermeture du programme et sa réexécution dans un contexte administratif. La plupart ne cachent même pas la mise à jour téléchargée et doivent tout recommencer.
Il serait bien mieux que le système de mise à jour automatique demande simplement les informations d'identification de l'administrateur, le cas échéant, et s'en occupe.
La méthode la plus simple consiste à demander à votre programme d’interroger un serveur (site Web) pour savoir s’il existe une mise à jour. S'il y a une mise à jour, vous pouvez afficher un message à l'utilisateur, l'invitant à télécharger une version plus récente et fournissant un lien.
Une solution alternative plus complexe serait de créer un petit service Windows (ou un démon Unix) qui vérifie périodiquement s'il existe des mises à jour. Ce service peut télécharger la mise à jour et lancer le programme d'installation.
L’architecture générale est que vous contrôlez un serveur central qui connaît la dernière version et où l’obtenir. Ensuite, les programmes interrogent le serveur. Je ne vais pas inclure d’exemple de code car il est très défendant sur le serveur et le format que vous choisissez. Ce n'est pas terrible difficile cependant.
La mise à jour automatique étant un scénario courant, la plupart des langues disposent d'au moins un package pour prendre en charge cette opération. (Ci-dessous je liste certains des paquets disponibles)
Une des idées vraiment sympas est la ClickOnce distribution pour .NET, c’est un programme d’installation qui met en sandbox votre application et l’installe dans le contexte utilisateur. Vous pouvez configurer ClickOnce dans votre publication pour vérifier les mises à jour que chaque application démarre.
Java a Java Web Start qui offre le même type de fonctionnalité pour les applets Java.
Delphi a publié de nombreux articles sur la mise à jour automatique, Torry possède une liste de Les composants WebUpdate , par exemple GoUpdater semblent avoir un très large éventail de fonctionnalités.
Ils utilisent tous un partage de site Web/réseau pour rechercher une nouvelle version, puis récupèrent un correctif ou un fichier d'installation complet et l'exécutent. Vous devez donc essayer de trouver un package Nice pour votre application, afin d’éviter les soucis liés au développement et à la maintenance de votre propre solution.
Vous pouvez écrire un module interne de votre application pour effectuer des mises à jour. Vous pouvez écrire une mini application externe pour effectuer des mises à jour.
Regardez également la technologie de compilation .NET à la volée, il est possible de créer une telle mini application à la volée à la demande. Par exemple, http://fly.sf.net/
Dans un paramètre Java-Webstart, vous démarrez un fichier JNLP qui déclenche ensuite le téléchargement des fichiers Jar nécessaires à l'exécution de l'application. Webstart Everytime vérifie s'il existe des versions plus récentes des fichiers JAR et les téléchargera en remplacement des versions mises en cache localement. Avec un outil nommé jardiff, vous ne créerez que des diffs vers les nouveaux jars et vous les distribuerez via le serveur (par exemple, vous ne recevrez qu'une mise à jour).
Avantages:
- toujours au courant
Les inconvénients:
- vous avez besoin d'un serveur d'applications (Tomcat, JBoss) pour pouvoir distribuer les fichiers
- vous avez besoin d'une connexion Internet pour obtenir l'application
La lecture de la réponse de Carl Seleborgs m’a donné quelques idées sur l’utilité d’un référentiel de code générique.
svn est livré avec un outil appelé svnsync, qui se comporte en quelque sorte comme une exportation svn mais conserve la trace de la révision actuelle de votre exportation.
Quelqu'un pourrait utiliser ce système pour extraire uniquement les fichiers modifiés de la révision réelle de l'utilisateur.
En réalité, vous aurez un référentiel avec les fichiers binaires compilés et l'exécution de svnsync ne récupérera que les fichiers binaires modifiés. Il pourrait également être en mesure de fusionner des modifications locales dans des fichiers de configuration textuels avec de nouvelles options de configuration.
Si votre logiciel est une source ouverte et ciblez Linux ou les développeurs. Il est intéressant d’installer votre logiciel en tant que dépôt Git. Et le faire tirer de temps en temps ou à chaque fois que la branche stable est lancée.
Ceci est particulièrement facile lorsque votre application est gérée via npm, sbt, mavan, stack, Elm-package ou similaire.
L’installation d’un correctif dans un programme est l’une des fonctions de base d’un installateur. Le logiciel d’installation est documenté à de nombreux endroits, mais habituellement par installateur: le Microsoft Installer (avec Install Shield Extensions), Ruby gems , Java .jar files, les différents systèmes systèmes de gestion de paquets ( RPM , Apt-get ) et autres.
Ce sont tous des systèmes complexes qui résolvent le problème du programme de correction en général, mais pour des systèmes légèrement différents. Pour décider de ce qui vous convient le mieux, déterminez le système auquel votre application ressemble le plus. Rouler soi-même, c'est bien, mais regarder ces systèmes est un point de départ.
Je vais assumer la réponse pour Windows.
Cette façon semble bien fonctionner.
Dans l'installateur, faites:
1. Créez un service à démarrage manuel qui s'exécute en tant que LocalSystem qui, une fois démarré, effectue la mise à jour puis s'arrête.
2. Modifiez les autorisations du service pour que tous les utilisateurs puissent démarrer le service (si tous les utilisateurs doivent pouvoir mettre à jour leurs droits d'administrateur).
3. Modifiez le programme principal pour vérifier les mises à jour au démarrage à l'aide d'un mécanisme simple. S'il détecte une mise à jour, Demander si l'utilisateur souhaite l'appliquer.
4. Si l'utilisateur accepte la mise à jour, démarrez le service.
Si l'architecture le permet, créez un moyen de surveiller la mise à jour en cours d'exécution.
Vous pouvez utiliser ma solution (partie de Target Eye projet) . http://www.codeproject.com/Articles/310530/Target-Eye-Revealed-part-Target-Eyes-Unique -Auto