Utilizzo di un repository Apt per aggiornamenti software a pagamento

Sto cercando di determinare un modo per distribuire gli aggiornamenti software per un'applicazione Web ospitata / in loco che può avere aggiornamenti settimanali e / o mensili. Non voglio che i clienti che utilizzano il prodotto in loco debbano preoccuparsi di aggiornarlo manualmente, ma voglio solo che scarichi e installi automaticamente su Google Chrome. Sto pensando di fornire un file OVF con Ubuntu e il software installato e configurato.

Il mio primo pensiero su come distribuire software è creare sei repository / canali Apt (non sono sicuro quale sarebbe meglio a questo punto) a cui si accederà tramite SSH usando le chiavi, quindi se un cliente non rinnova l'abbonamento possiamo disabilitare il suo account :

1. Beta: utilizzato internamente sui dati di test per verificare la presenza di difetti importanti nel pacchetto.
2. Interno: utilizzato internamente su dati in tempo reale per verificare la presenza di difetti nel pacchetto (fase dell'alimentazione del cane).
3. Esterno 1: distribuito all'1% della nostra base di utenti (selezionata casualmente) per verificare la presenza di difetti.
4. Esterno 9: distribuito al 9% della nostra base di utenti (selezionato casualmente) per verificare la presenza di difetti.
5. Esterno 90: distribuito al restante 90% degli utenti.
6. Ospitato: distribuito nell'ambiente ospitato.

Ci vorrà un segno in ogni fase per passare al repository successivo nel caso in cui vengano segnalati problemi.

Le mie domande alla comunità sono:

1. Qualcuno ha provato qualcosa di simile prima?
2. Qualcuno può vedere un aspetto negativo di questo tipo di procedura?
3. Esiste un modo migliore?

Nel complesso, adoro l'approccio. In ogni caso, i problemi di pirateria non possono essere contrastati, sia che si tratti di una distribuzione tradizionale o automatizzata, e si può evitare l'inconveniente di un sistema di licenze.

Potresti avere problemi con le selezioni casuali. Un cliente è scelto per essere uno dei primi ad adottare per tutta la durata del rapporto d'affari? In caso contrario, come si può realizzare un downgrade da 1 esterno a 9 esterno?

Hai pensato alle licenze generali e alla protezione del tipo di telefono per il tuo software?

Il problema che vedo qui (senza alcuna licenza) è che posso pagare per un mese, interrompere, quindi continuare a correre su questa versione. Certo è vecchio, ma è gratuito. Questa scappatoia sarà sfruttata da almeno alcune persone

Se si dispone già di licenze, è sufficiente disporre di semplici repository non protetti con il software che richiede il controllo della licenza prima dell'esecuzione

Non conosco abbastanza il tuo software e / o la natura dei tuoi clienti, ma in molti punti gli aggiornamenti non vengono installati senza essere testati. Molte aziende utilizzano una chiave di licenza che scadrà. Consentire loro di scaricare l'aggiornamento e avviarlo manualmente. Gli aggiornamenti automatici sono convenienti, ma a volte agli utenti non piacciono le sorprese.

Dai un'occhiata al framework Sparkle per OS X, fa una cosa molto simile al meccanismo di aggiornamento di Chrome ma fornisce feedback degli utenti in modo che possano saltare l'aggiornamento o farlo in seguito. Ho avuto l'aggiornamento delle applicazioni su di me e ho cambiato le funzionalità di cui avevo bisogno così com'era, sempre meglio chiedere almeno all'utente.

Mi piace l'idea adatta, però ha senso farlo in questo modo, è semplice e davvero molto ben testato a questo punto.

Conosco un'azienda che sta facendo quasi esattamente ciò che hai descritto. (Meno livelli di quelli che hai descritto e non so come si stanno autenticando.)

Il problema più grande che hanno avuto è che alcuni clienti bloccano l'accesso a Internet dal proprio dispositivo. Ciò significa che quei clienti sono semplicemente bloccati alla versione che hanno installato. Forse va bene. Penso che abbiano discusso dell'apertura delle regole del firewall con alcuni di quei clienti. Altri hanno appena aggiornato manualmente.

Se dovessi farlo, lo farei in base all'indirizzo IP. Quindi quando arrivano per scaricare il loro indirizzo IP deve essere nell'elenco autorizzato per connettersi a quel server, altrimenti non possono scaricare. Fa schifo se non hanno un IP dedicato ma è improbabile da quello che sembra che tu stia parlando se è basato su server se è per stazioni di lavoro, allora potresti essere meglio configurarli con il proprio server apt interno e quindi che i download una copia tramite cron job o qualcosa su ftp e così via una volta alla settimana e poi le stazioni di lavoro vengono scaricate da lì fino a te.

Questo è un buon approccio stagionato.

Alcune insidie ​​da considerare:

• Potresti non voler sempre andare all'1 percento, 9 percento, 90 percento. I tuoi clienti potrebbero non essere omogenei, il che significa che potresti voler iniziare a specializzarti, diciamo, per regione, per tipo di dispositivo, ecc. Nel qual caso una distribuzione dell'1,99 90% a livello globale non ha più senso.

• Avere un unico repository per il 90 percento dei tuoi utenti introduce l' hotspotting : quel server subirà la maggior parte delle richieste, il che significa che sarà il primo a morire in caso di un aumento del traffico, causando un'interruzione del 90 percento dei tuoi utenti. La ridondanza aiuta, ovviamente, ma ciò comporta un aumento delle spese complessive.

• Potresti avere un flusso di lavoro in cui alcune funzioni sono pronte per la distribuzione al 90 percento di tutti gli utenti, ma un aggiornamento globale farà sì che le funzioni non pronte per l'adozione al 90 percento colpiscano la produzione, introducendo colli di bottiglia nel flusso di lavoro degli sviluppatori. Una distribuzione fissa non sarà in grado di gestire efficacemente questi problemi, costringendoti a gestirlo a livello di applicazione.

Un modo per correggere ciò consiste nel mantenere più copie dei repository di produzione su server diversi, posizionare un bilanciamento del carico configurabile di fronte ad esso e quindi aggiornare attentamente i repository di produzione su base continuativa. In altre parole, considera tutti i repository che alla fine desiderano essere uguali, ma configura il traffico in modo che la percentuale di utenti che leggono da un server sia modificabile.

Il vantaggio è che puoi configurare la distribuzione delle richieste a tuo piacimento usando il tuo bilanciamento del carico, puoi ridimensionare orizzontalmente meglio (tutti i tuoi server possono iniziare a servire lo stesso repository in modo proporzionale se tutte le funzionalità sono pronte per l'adozione al 100%) e, a seconda di come Il flusso di lavoro del team è e la tua necessità di aggiornamenti specifici per regione, puoi eventualmente consentire a determinate funzionalità di essere immediatamente disponibili senza preoccuparti delle altre funzionalità.