Domanda

Molti programmi includono un aggiornamento automatico, in cui il programma cerca occasionalmente online gli aggiornamenti, quindi scarica e applica tutti gli aggiornamenti trovati. I bug del programma vengono corretti, i file di supporto vengono modificati e le cose (di solito) migliorate.

Sfortunatamente, non importa quanto sembri difficile, non riesco a trovare informazioni su questo processo da nessuna parte. Sembra che gli aggiornamenti automatici implementati siano stati proprietari o non considerati importanti.

Sembra abbastanza facile implementare il sistema che cerca gli aggiornamenti su una rete e li scarica se sono disponibili. Quella parte dell'aggiornamento automatico cambierà significativamente da un'implementazione all'altra. La domanda è: quali sono i diversi approcci per applicare le patch. Basta scaricare file e sostituire quelli vecchi con quelli nuovi, eseguire uno script di migrazione che è stato scaricato, scimmiettare patch su parti del sistema, ecc.? I concetti sono preferiti, ma sarebbero apprezzati esempi in Java, C, Python, Ruby, Lisp, ecc.

È stato utile?

Soluzione

Penso che "agnostico del linguaggio" sarà un fattore limitante qui. Le applicazioni sono disponibili in così tante forme e dimensioni che non esiste una risposta valida per tutti. Ho implementato diversi aggiornamenti automatici in diverse lingue e non ce n'erano due simili.

La filosofia più generale è che l'applicazione controlla con qualche posizione di casa (indirizzo web, query web, posizione della rete aziendale, ecc.) per chiedere se la sua versione è attuale o per chiedere quale sia la versione più attuale. Se la risposta richiede un aggiornamento, tale processo sarà diverso per ogni situazione.

Un'alternativa popolare è quella di invitare il luogo di residenza per eseguire uno script all'avvio dell'applicazione. Lo script può controllare la versione, scaricare gli aggiornamenti se necessario e chiedere feedback sull'utilizzo, ad esempio.

Probabilmente possiamo aiutare meglio se restringi i parametri.

AGGIORNAMENTO: l'approccio a " patching " dipende anche dalla natura dell'applicazione e qui c'è una diversità molto ampia. Se hai un singolo file eseguibile, ad esempio, è probabilmente più pratico sostituire l'eseguibile. Se la tua applicazione ha molti file, dovresti cercare modi per ridurre al minimo il numero di file sostituiti. Se la tua applicazione è altamente personalizzata o parametrizzata, dovresti cercare di ridurre al minimo lo sforzo di adattamento. Se l'applicazione utilizza un codice interpretato (ad esempio un'applicazione VBA di Excel o un'applicazione MDB di MS Access), è possibile sostituire parti del codice. In un'applicazione Java potrebbe essere necessario sostituire solo un file JAR o anche un sottoinsieme dei contenuti JAR. Dovrai anche avere un modo per riconoscere la versione corrente del client e aggiornarla in modo appropriato. Potrei andare avanti all'infinito, ma spero che tu veda il mio punto sulla diversità. Questa è una di quelle tante volte in cui la risposta migliore di solito inizia con " Beh, dipende ...! & Quot; Ecco perché così tante risposte includono " Per favore restringi i parametri. & Quot;

Altri suggerimenti

Assicurati di considerare anche le implicazioni di sicurezza dell'aspirazione delle informazioni sull'aggiornamento, così come i file binari di aggiornamento stessi.

Ti fidi della fonte del download? Forse stai telefonando a casa per ottenere il tuo aggiornamento, ma cosa succede se nel mezzo c'è un uomo che reindirizza a un server dannoso. Sarà utile un HTTPS o una connessione protetta simile, ma si consiglia di ricontrollare i bit eventualmente scaricati utilizzando un controllo della firma digitale.

Per prima cosa è necessario un file sul sito Web principale dell'applicazione con l'ultima versione. Il modo migliore penso di avere una tabella SQL speciale per questa attività e compilarla automaticamente dopo la pubblicazione di una nuova versione / completamento notturno della build. L'applicazione crea un nuovo thread che richiede il collegamento http incorporato con la versione e si confronta con l'attuale. In .NET l'uso può usare codice come questo:

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
}

In questo esempio, version.php in una sola stringa semplice come 1.0.1.0.

Un altro suggerimento che posso dare: come scaricare un aggiornamento. Mi piace moltissimo la prossima idea: nelle risorse della tua applicazione c'è una stringa di codice CLR che compili al volo (usando CodeDom) in una cartella temporanea, l'applicazione principale lo chiama e va a chiudere. Il programma di aggiornamento legge argomenti, impostazioni o registro e scarica nuovi moduli. E chiama l'applicazione principale che elimina tutti i file temporanei. Fatto!

(Ma tutto qui riguarda .NET)

Le soluzioni più semplici (utilizzate da molti programmi) sono l'esecuzione del programma di disinstallazione per la versione precedente e l'esecuzione del programma di installazione per quella nuova (saltando facoltativamente le domande a cui l'utente ha già risposto, come l'EULA). L'unico problema è che la nuova versione deve essere in grado di leggere le opzioni di configurazione dalla versione precedente.

Inoltre, su Windows non puoi eliminare un file eseguibile in uso, quindi probabilmente vorrai rilasciare un piccolo eseguibile nella cartella Temp, che esegue l'intero processo e quindi lo elimina alla fine dall'istanza di la nuova versione che è stata lanciata (o solo registrala per eliminarla al prossimo riavvio ).

L'approccio più semplice sarebbe fare in modo che il programma esegua una query su un server (sito Web) per vedere se è presente un aggiornamento. Se è presente un aggiornamento, è possibile visualizzare un messaggio all'utente che richiede di scaricare una versione più recente e fornisce un collegamento.

Una soluzione alternativa e più complessa sarebbe quella di creare un piccolo servizio Windows (o demone unix) che controlli periodicamente per vedere se ci sono aggiornamenti, questo servizio può scaricare l'aggiornamento e avviare il programma di installazione.

L'architettura generale è che hai un server centrale che controlli che conosce l'ultima versione e dove trovarlo. Quindi i programmi interrogano il server. Non includerò il codice di esempio perché è altamente imputato sul server e sul formato scelto. Non è terribile, però.

Questa non è tanto una risposta completa, quanto piuttosto un esempio di meccanismo di aggiornamento automatico che ho implementato di recente. La situazione è un po 'diversa dalla tradizionale applicazione utente di tipo Firefox, poiché era uno strumento interno utilizzato al lavoro.

Fondamentalmente, è un piccolo script che gestisce una coda di rami di Subversion da creare e impacchettare in un programma di installazione. Legge un piccolo file, in cui sono scritti i nomi dei rami, prende il primo, lo riscrive alla fine del file e avvia il processo di compilazione, che comporta la chiamata di un gruppo di script. La configurazione per ogni ramo da compilare è scritta in un file .INI, memorizzato in un repository Subversion insieme allo strumento stesso.

Poiché questo strumento viene eseguito su più computer, volevo un modo per aggiornarlo automaticamente su tutte le macchine non appena ho apportato una modifica allo strumento stesso o agli script di configurazione.

Il modo in cui l'ho implementato era semplice: quando lancio lo strumento, diventa un "guscio esterno". Questa shell esterna fa 2 cose molto semplici:

  • svn update su se stesso e sui file di configurazione
  • si avvia di nuovo, questa volta come la "shell interna", quella che gestisce effettivamente una configurazione (e quindi esce di nuovo).

Questo semplicissimo sistema update-me-in-a-loop ci è servito molto bene da alcuni mesi. È molto elegante, perché è autonomo: l'auto-aggiornamento è il programma stesso. Perché "guscio esterno" (la parte dell'aggiornamento automatico) è così semplice, non importa che non tragga beneficio dagli aggiornamenti come la "shell interna" (che viene eseguito ogni volta dal file sorgente aggiornato).

Una cosa che non è stata veramente menzionata è che dovresti considerare seriamente che l'utente che esegue il tuo programma potrebbe non avere effettivamente i privilegi sufficienti per aggiornarlo. Questo dovrebbe essere abbastanza comune almeno per gli utenti aziendali, probabilmente meno per gli utenti domestici.

Lavoro sempre con un account limitato (autoimposto) per motivi di sicurezza e mi fa sempre incazzare il fatto che la maggior parte degli auto-aggiornamenti presupponga semplicemente che sto eseguendo come amministratore e quindi dopo il download non riesco e non offro altro modo di eseguire l'aggiornamento diverso dalla chiusura effettiva del programma ed eseguirlo nuovamente in un contesto amministrativo. La maggior parte non memorizza nemmeno nella cache l'aggiornamento scaricato e deve ripetere tutto da capo.

Sarebbe molto meglio se l'aggiornamento automatico richiedesse semplicemente le credenziali di amministratore quando necessario e andasse avanti con esso.

Poiché l'aggiornamento automatico è uno scenario comune, la maggior parte delle lingue ha almeno un pacchetto disponibile per supportare questo. (Di seguito elencherò alcuni dei pacchetti disponibili)

Una delle idee davvero interessanti è la ClickOnce per .NET, è un programma di installazione che esegue il sandbox dell'applicazione e si installa nel contesto dell'utente, quindi non sono richiesti diritti di amministratore. Puoi configurare ClickOnce nella tua pubblicazione per verificare la presenza di aggiornamenti all'avvio di ogni applicazione.

Java ha Java Web Start che offre lo stesso tipo di funzionalità per le applet Java.

Delphi ha numerosi articoli sull'aggiornamento automatico, Torry ha un elenco di componenti WebUpdate , ad esempio GoUpdater sembra avere una gamma molto ampia di funzionalità.

Usano tutti un sito Web / una condivisione di rete per cercare una nuova versione e per recuperare una patch o un file di installazione completo ed eseguirlo. Quindi dovresti provare a trovare un bel pacchetto per la tua applicazione, per risparmiare il fastidio di sviluppare e mantenere la tua soluzione.

In un'impostazione Java-Webstart si avvia un file JNLP che avvia quindi il download dei file Jar necessari per eseguire l'applicazione. Ogni volta che il webstart verifica se ci sono versioni più recenti dei vasetti e li scarica sostituendo quelli memorizzati nella cache locale. Con uno strumento chiamato jardiff, creerai differenze solo verso i vasi più recenti e li distribuirai tramite il server (ad esempio ottieni solo un aggiornamento).

Pro:

  • sempre aggiornato

Contro:

  • è necessario un server delle applicazioni (tomcat, JBoss) per distribuire i file
  • è necessaria una connessione Internet per ottenere l'applicazione

La lettura della risposta di Carl Seleborg mi ha dato alcune idee su come un repository generico di codice potrebbe essere utile.

svn viene fornito con uno strumento chiamato svnsync, che in qualche modo si comporta come un'esportazione svn ma tiene traccia della revisione effettiva in cui si trova l'esportazione.

Qualcuno potrebbe utilizzare questo sistema per recuperare solo i file modificati dalla revisione effettiva dell'utente.

In realtà, avrai un repository con i binari compilati e eseguendo svnsync verranno recuperati solo i binari che sono stati modificati. Potrebbe anche essere in grado di unire le modifiche locali ai file di configurazione basati su testo con nuove opzioni di configurazione.

La funzione di installare una patch in un programma è sostanzialmente una delle funzioni di base di un programma di installazione. Il software di installazione è documentato in numerosi punti ma di solito in base all'installazione: lì Microsoft Installer (con Install Shield Extensions), Gemme di rubini , file Java .jar , i vari sistemi di gestione dei pacchetti Linux ( RPM , Apt-get ) e altri.

Questi sono tutti sistemi complessi che risolvono il problema del programma di patching in generale, ma per sistemi leggermente diversi. Per decidere cosa è meglio per te, considera quale di questi sistemi assomiglia di più alla tua applicazione. Rotolare il tuo va bene, ma guardare questi sistemi è un punto di partenza.

Puoi scrivere un modulo interno della tua applicazione per fare aggiornamenti. Puoi scrivere una mini applicazione esterna per fare aggiornamenti.

Guarda anche la tecnologia di compilazione .NET on-the-fly, che rende possibile creare tale mini-applicazione al volo su richiesta. Ad esempio, http://fly.sf.net/

Presumo la risposta per Windows.

In questo modo sembra funzionare bene.

Nel programma di installazione fare:
1. Creare un servizio di avvio manuale che viene eseguito come LocalSystem che quando avviato esegue l'aggiornamento, quindi si interrompe.
2. Modificare le autorizzazioni del servizio in modo che tutti gli utenti possano avviare il servizio (se tutti gli utenti devono essere in grado di aggiornare senza i diritti di amministratore).
3. Modificare il programma principale per verificare la presenza di aggiornamenti quando avviato utilizzando un semplice meccanismo. Se rileva un aggiornamento, chiedere all'utente se desidera applicarlo.
4. Se l'utente accetta l'aggiornamento, avviare il servizio.

Se l'architettura lo consente, creare un modo per monitorare l'aggiornamento mentre è in esecuzione.

Se il tuo software è open source e indirizza Linux o gli sviluppatori. È interessante installare il software come repository git. E farlo tirare il ramo stabile occasionalmente o ogni volta che viene lanciato.

Ciò è particolarmente semplice quando l'applicazione è gestita tramite npm, sbt, mavan, stack, elm-package o simili.

Se stai cercando una soluzione di aggiornamento software multipiattaforma, dai un'occhiata a www.updatenode.com

Alcuni punti salienti:

  • gratuito per progetti Open Source
  • multipiattaforma e amp; Strumento client di aggiornamento Open Source
  • già localizzato per le lingue più importanti
  • facile da integrare e facile da gestire
  • piattaforma di gestione basata su cloud per definire e gestire gli aggiornamenti
  • fornisce inoltre supporto per la visualizzazione di messaggi (informa su nuovi eventi, prodotti, ecc.)
  • l'interfaccia web è aperta (puoi creare il tuo client usando il servizio)
  • molte statistiche di utilizzo, come sistemi operativi usati, posizione geografica, utilizzo della versione, ecc.
  • API Android per aggiornamenti app mobili

Provalo.

A proposito, faccio parte del team di sviluppo per il client open source. :)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top