Utilisation d'un référentiel Apt pour les mises à jour logicielles payantes

J'essaie de déterminer un moyen de distribuer les mises à jour logicielles pour une application Web hébergée / sur site qui peut avoir des mises à jour hebdomadaires et / ou mensuelles. Je ne veux pas que les clients qui utilisent le produit sur site aient à se soucier de le mettre à jour manuellement. Je veux juste qu'il se télécharge et s'installe automatiquement sous Google Chrome. Je prévois de fournir un fichier OVF avec Ubuntu et le logiciel installé et configuré.

Ma première pensée sur la façon de distribuer des logiciels est de créer six référentiels / canaux Apt (je ne sais pas ce qui serait mieux à ce stade) qui seront accessibles via SSH à l'aide de clés, donc si un client ne renouvelle pas son abonnement, nous pouvons désactiver son compte :

1. Bêta - Utilisé en interne sur les données de test pour vérifier le package pour les défauts majeurs.
2. Interne - Utilisé en interne sur les données en direct pour vérifier le paquet pour les défauts (étape de l'alimentation des chiens).
3. Externe 1 - Déployé sur 1% de notre base d'utilisateurs (sélectionnés au hasard) pour vérifier les défauts.
4. Externe 9 - Déployé sur 9% de notre base d'utilisateurs (sélectionnés au hasard) pour vérifier les défauts.
5. Externe 90 - Déployé sur les 90% d'utilisateurs restants.
6. Hébergé - Déployé dans l'environnement hébergé.

Il faudra une signature à chaque étape pour passer au référentiel suivant en cas de problèmes signalés.

Mes questions à la communauté sont:

1. Quelqu'un a-t-il déjà essayé quelque chose comme ça?
2. Quelqu'un peut-il voir un inconvénient à ce type de procédure?
3. Y a-t-il une meilleure façon?

Dans l'ensemble, j'adore l'approche. Les problèmes de piratage ne peuvent pas être contrés de toute façon, que ce soit par une distribution traditionnelle ou automatisée, et vous pouvez éviter les inconvénients d'un système de licence.

Vous pourriez avoir des problèmes avec les sélections aléatoires. Un client est-il choisi pour être un adopteur précoce pour toute la durée de votre relation commerciale? Sinon, comment une rétrogradation de externe 1 à externe 9 peut-elle être réalisée?

Avez-vous pensé à une licence générale et à une protection de type home téléphonique pour votre logiciel?

Le problème que je vois ici (sans aucune licence) est que je peux payer pendant un mois, arrêter, puis continuer à fonctionner sur cette version. Bien sûr, c'est vieux, mais c'est gratuit. Cette faille sera exploitée par au moins certaines personnes

Si vous disposez déjà d'une licence, il vous suffit de disposer de référentiels simples non protégés avec le logiciel nécessitant de vérifier la licence avant de l'exécuter.

Je ne connais pas suffisamment votre logiciel et / ou la nature de vos clients, mais dans de nombreux endroits, les mises à jour ne sont pas installées sans avoir été testées. De nombreuses entreprises utilisent une clé de licence qui expirera. Permettez-leur de télécharger la mise à jour et de lancer manuellement. Les mises à jour automatiques sont pratiques, mais parfois les utilisateurs n'aiment pas les surprises.

Jetez un œil au cadre Sparkle pour OS X, il fait une chose très similaire au mécanisme de mise à jour de Chrome mais fournit des commentaires aux utilisateurs afin qu'ils puissent ignorer la mise à jour ou le faire plus tard. J'ai eu des mises à jour d'applications sur moi et j'ai changé les fonctionnalités dont j'avais besoin, c'était toujours mieux de demander au moins à l'utilisateur.

J'aime bien l'idée appropriée, il est logique de le faire de cette façon, c'est simple et vraiment, vraiment bien testé à ce stade.

Je connais une entreprise qui fait presque exactement ce que vous avez décrit. (Moins de niveaux que vous avez décrits, et je ne sais pas comment ils s'authentifient.)

Le plus gros problème qu'ils ont rencontré est que certains clients bloquent l'accès à Internet depuis leur appareil. Cela signifie que ces clients sont simplement verrouillés sur la version qu'ils ont installée. C'est peut-être bien. Je pense qu'ils ont discuté de l'ouverture des règles de pare-feu avec certains de ces clients. D'autres viennent d'être mis à niveau manuellement.

Si je devais le faire, je le ferais en fonction de l'adresse IP. Donc, quand ils viennent télécharger leur adresse IP, ils doivent être sur la liste autorisée pour se connecter à ce serveur, sinon ils ne peuvent pas télécharger. Cela craint s'ils n'ont pas d'IP dédiée, mais peu probable de ce que vous dites si c'est basé sur un serveur si c'est pour des postes de travail, alors vous feriez mieux de les configurer avec leur propre serveur apt en interne et ensuite que les téléchargements une copie via cron job ou quelque chose sur ftp et ainsi de suite une fois par semaine, puis il y a des postes de travail à télécharger à vous.

Il s'agit d'une bonne approche chevronnée.

Quelques pièges à considérer:

• Vous ne voudrez peut-être pas toujours aller de 1%, 9%, 90%. Vos clients peuvent ne pas être homogènes, ce qui signifie que vous voudrez peut-être commencer à vous spécialiser, par exemple, par région, par type d'appareil, etc. auquel cas une distribution de 1, 9, 90 pour cent à l'échelle mondiale n'a plus de sens.

• Le fait d'avoir un référentiel unique pour 90% de vos utilisateurs introduit le hotspotting - ce serveur subira la majeure partie des demandes, ce qui signifie qu'il sera le premier à mourir en cas de pics de trafic, provoquant une panne pour 90% de vos utilisateurs. La redondance aide, bien sûr, mais cela entraîne globalement plus de dépenses.

• Vous pouvez avoir un flux de travail où certaines fonctionnalités sont prêtes à être distribuées à 90% de tous les utilisateurs, mais une mise à jour globale entraînera la mise en production de fonctionnalités qui ne sont pas prêtes à 90%, introduisant des goulots d'étranglement dans votre flux de travail de développement. Une distribution fixe ne sera pas en mesure de gérer efficacement ces problèmes, ce qui vous obligera à gérer cela au niveau de l'application.

Un moyen de corriger cela consiste à conserver plusieurs copies des référentiels de production sur différents serveurs, à placer un équilibreur de charge configurable devant lui , puis à mettre à jour soigneusement vos référentiels de production de manière incrémentielle sur une base continue. En d'autres termes, traitez tous les référentiels comme voulant finalement être les mêmes, mais configurez le trafic afin que le pourcentage d'utilisateurs lisant à partir d'un serveur soit modifiable.

L'avantage est que vous pouvez configurer la distribution des demandes à volonté à l'aide de votre équilibreur de charge, vous pouvez mieux évoluer horizontalement (tous vos serveurs peuvent commencer à servir le même référentiel proportionnellement si toutes les fonctionnalités sont prêtes pour une adoption à 100%), et, selon la façon dont votre le flux de travail de l'équipe est et votre besoin de mises à jour spécifiques à la région, vous pouvez éventuellement autoriser certaines fonctionnalités à être disponibles immédiatement sans se soucier des autres fonctionnalités.