Utilizzo di un repository Apt per aggiornamenti software a pagamento

Nel complesso, adoro l'approccio. I problemi di pirateria non possono essere neutralizzati comunque, sia con la distribuzione tradizionale o automatizzata, ed è possibile evitare l'inconveniente di uno schema di licenza.

Potresti avere problemi con le selezioni casuali. Un cliente è scelto come precoce per tutta la durata della sua relazione d'affari? Altrimenti, come si può realizzare un downgrade da esterno 1 a esterno 9?

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

Mi piace l'idea giusta, ha senso farlo in questo modo, è semplice e davvero, davvero ben collaudato a questo punto.

Conosco un'azienda che sta facendo esattamente quello che hai descritto. (Meno livelli di quelli che hai descritto, e non so in che modo si stanno autenticando.)

Il problema più grande che hanno avuto è che alcuni clienti bloccano l'accesso a Internet dal proprio dispositivo. Ciò significa che i 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 questi clienti. Altri sono stati aggiornati manualmente.

Se dovessi farlo lo farei in base all'indirizzo IP. Quindi quando vengono a scaricare il loro indirizzo ip deve essere sulla lista consentita per connettersi a quel server altrimenti non possono scaricare. Fa schifo se non hanno un ip dedicato ma improbabile da come sembra che tu stia parlando se è basato su server se è per postazioni di lavoro, allora potresti trovarti meglio installarlo con il proprio server apt inhouse e poi quello download una copia via cron job o qualcosa su ftp e così via una volta alla settimana e poi ci sono download di postazioni da lì davvero da te.

Questo è un buon approccio stagionato.

Alcune trappole da considerare:

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

• Avere un unico repository per il 90% dei tuoi utenti introduce hotspotting - che il server sperimenterà la maggior parte delle richieste, il che significa che sarà il primo a morire in caso di traffico impennata, causando un'interruzione per il 90% dei tuoi utenti. La ridondanza aiuta, ovviamente, ma introduce una maggiore spesa complessiva.

• Potresti avere un flusso di lavoro in cui determinate funzionalità sono pronte per la distribuzione al 90% di tutti gli utenti, ma un aggiornamento globale causerà funzionalità non pronte all'adozione del 90% per colpire la produzione, introducendo colli di bottiglia nel flusso di lavoro dev. Una distribuzione fissa non sarà in grado di gestire efficacemente questi problemi, costringendoti a gestirli a livello di applicazione.

Un modo per correggere ciò è mantenere più copie dei repository di produzione su server diversi, posizionare un sistema di bilanciamento del carico configurabile di fronte a esso e quindi aggiornare attentamente i repository di produzione in modo incrementale su base continuativa . In altre parole, considera tutti i repository come se volessero essere uguali, ma configura il traffico in modo che la percentuale di utenti che leggono da un server sia variabile.

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

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

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

Se disponi già di licenze, disponi semplicemente di semplici repository non protetti con il software che richiede il controllo della licenza prima di eseguire

Non ne so abbastanza del tuo software e / o della natura dei tuoi clienti, ma in molti luoghi gli aggiornamenti non vengono installati senza essere testati. Molte aziende utilizzano una chiave di licenza che verrà interrotta. Consentire loro di scaricare l'aggiornamento e avviarlo manualmente. Gli aggiornamenti automatici sono convenienti, ma a volte gli utenti non amano le sorprese.