Avete mai affrontato il problema degli aggiornamenti automatici?
Io ho sempre eseguito gli aggiornamenti manualmente con la pubblicazione da INDE o con l’utilizzo di IdManager, vorrei fare in modo che IdManager in locale prendesse un file zip presente su un server pubblico e installasse l’aggiornamento.
E’ possibile? Ci sono degli altri modi?
Grazie,
Martina
4 Mi Piace
Sui server self-managed l’operazione è assolutamente possibile. Una parte del compito, quella dell’installazione, è descritta qui:
Per il recupero del pacchetto di installazione da un server, le soluzioni applicabili sono diverse, sempre nell’ambito dei server self-managed; nel caso specifico di IdManager purtroppo non saprei, non l’ho mai utilizzato.
@m.zaganelli non ha messo il tag idf (Foundation) al post e quindi @giorba ha risposto per quel che riguarda Instant Developer Cloud.
Grazie comunque @giorba.
Sì è vero @paolo.giannelli, non avevo specificato che parlavo di Foundation.
Mi è stato comunque utile leggere l’articolo di @giorba per capire la sue esperienza e quella di @f.faleschini che usa Foundation.
Grazie per il confronto!
Martina
1 Mi Piace
IDManager crea pacchetti differenti in base allo stato dell’applicazione che sta aggiornando. Potenzialmente, su 10 installazioni, ci saranno 10 pacchetti differenti.
Volendo permettere all’utente di decidere quando aggiornarsi, automatizzare dovrebbe implicare avere un unico repository in cui chi si occupa della della pubblicazione deposita tutti i pacchetti di aggiornamento “progressivo”. Quando l’utente vuole, questi pacchetti dovrebbero essere scaricati e passati allo idmanager del cliente nella sequenza corretta, che li applica uno alla volta.
Questa è l’idea, rimasta tale, a cui siamo arrivati. Sarebbe veramente interessante approfondire e sviluppare questa soluzione, o una equivalente, purtroppo le risorse sono quelle che sono…
1 Mi Piace
Sì esatto, siamo arrivati anche noi alla stessa idea.
Ne ho parlato con Matteo Sirri in un’assistenza e mi ha consigliato di fare una proposta di implementazione, facciamogli sapere che servirebbe a tanti di noi! @paolo.giannelli
10 Mi Piace
Grazie @m.zaganelli del feedback.
A tutti gli interessati ad una implementazione del genere chiedo di mettere mi piace alla risposta di Martina così diamo un peso alla cosa.
Il mio post ha ottenuto 5 mi piace, sono abbastanza?
Forse non è visibile a sufficienza, credo che potrebbe essere utile a molti, altrimenti come si possono gestire gli aggiornamenti evitando la parte manuale, come si può fare in ogni programma?
Grazie,
Martina
2 Mi Piace
@m.zaganelli direi che la proposta è comunque interessante e potrebbe essere proposta come nuova funzionalità di Instant Developer Foundation e questo lo potresti fare anche tu da CRM Pro Gamma.
La cosa che mi piacerebbe capire insieme è quale sia il miglior modo di farlo così da proporre la soluzione come modifica la soluzione che sia più vicina alle esigenze di tutti, ti va di essere tu redigere una piccola analisi di questa nuova funzionalità per IDManager?
L’analisi che avevo pensato è molto breve, scrivo qui la mia idea poi mi dici se è sufficiente oppure no.
IDManager dovrebbe essere installato su un server pubblico ed avere una WebAPI collegata da poter interrogare passandogli questi parametri:
- indirizzo del server pubblico
- autenticazione con username e password
- nome applicazione da aggiornare
- tipo installazione
- file zip nominato “VersioneAttuale_VersioneFutura.zip”
Quando viene richiamata la WebAPI, il programma IDManager installerà l’aggiornamento allo stesso modo di quando gli viene inviato il file zip sull’applicazione web, poi restituisce il risultato OK/FALLITO.
Cosa ne pensate? Scrivo la stessa cosa anche sul CRM di Pro Gamma come nuova funzionalità proposta?
1 Mi Piace
Vediamo se ho capito: chi pubblica dovrebbe creare il pacchetto di aggiornamento collegandosi ad una installazione tipo. Poi, tramite un’altra applicazione che utilizza le web api di idmanager, spedire quel pacchetto in modo massivo a tutti gli idmanager.
Mi piace la linearità e la semplicità della soluzione, però ho alcuni dubbi:
- Se uno degli aggiornamenti fallisse, si dovrebbe procedere nel vecchio modo per riallineare quella specifica installazione, prima di poter procedere ad un nuovo aggiornamento massivo.
- Chi pubblica dovrebbe avere accesso agli idmanager di tutti i clienti, che potrebbero risiedere nella loro rete interna, con necessità quindi di VPN o altre soluzioni sistemistiche.
- Il processo di pubblicazione richiederebbe il tempo di invio del pacchetto per tutte le installazioni, potenzialmente numeroso.
Ribaltando la soluzione, se per ogni applicazione creassimo un repository pubblico in cui chi installa posiziona i pacchetti di aggiornamento, ogni idmanager dovrebbe scaricare e processare questi pacchetti nell’ordine giusto, senza l’intervento di chi pubblica. Potrebbe essere anche un’applicazione installata al fianco di idmanager che si occupa di scaricare e passare ad di manager i pacchetti, ma non mi piace molto l’idea di avere due applicazioni che si occupano sostanzialmente della stessa cosa.
Ovviamente, le mie sono solo idee e derivano dalla nostra situazione, in cui potenzialmente potremmo avere 500 installazioni della stessa applicazione.
La mia idea era proprio quella di creare un’applicazione con repository pubblico dove
- posizionare i pacchetti di aggiornamento,
- inserire la lista di tutti gli IDManager con sito pubblicato su Internet (per gli altri non si riuscirebbe a svolgere questa attività)
- la versione di programma installata, in modo che l’applicazione invii alla web api di IDManager i pacchetti giusti nell’ordine corretto.
Noi al momento noi avremmo dei numeri più bassi, quindi credo che si potrebbe gestire l’attività schedulandola in orari notturni.
Grazie per il tuo contributo!
Mi accodo alla richiesta
Aggiungo che, se le modifiche sono solo a livello di codice le tempistiche potrebbero anche essere accettabili, ma nel caso di modifiche alla struttura db può far salire esponenzialmente la durata del processo di aggiornamento. Nel nostro caso ogni istanza di IDManager ha diverse decine di DB da tenere aggiornarti e risiedendo su macchine diverse l’intoppo è sempre in agguato…
Anche a me interessa molto il tema e andrebbe potenziato l’aspetto già proposto di “cosa fare se una installazione fallisce”. Potrebbe richiedere il rollback di tutte le installazioni o ignorare e segnalare. Penso ad una distribuzione di più installazioni (per un bilanciamento del carico) o installazioni singole ed indipendenti per vari clienti. Il tutto si collega a mio parere anche alla possibilità di lavorare su netcore linux con docker ma su questo specifico punto aprirò una discussione dedicata.