Uso de un repositorio de Apt para actualizaciones de software de pago

Estoy tratando de determinar una forma de distribuir actualizaciones de software para una aplicación web alojada / en el sitio que puede tener actualizaciones semanales y / o mensuales. No quiero que los clientes que usan el producto en el sitio tengan que preocuparse por actualizarlo manualmente, solo quiero que se descargue e instale automáticamente en Google Chrome. Estoy planeando proporcionar un archivo OVF con Ubuntu y el software instalado y configurado.

Mi primer pensamiento sobre cómo distribuir el software es crear seis repositorios / canales Apt (no estoy seguro de cuál sería mejor en este momento) a los que se accederá a través de SSH usando claves, por lo que si un cliente no renueva su suscripción, podemos deshabilitar su cuenta :

1. Beta: se utiliza internamente en los datos de prueba para verificar si el paquete tiene defectos importantes.
2. Interno: se usa internamente en datos en vivo para verificar si el paquete tiene defectos (etapa de alimentación del perro).
3. Externo 1: implementado en el 1% de nuestra base de usuarios (seleccionado al azar) para verificar defectos.
4. Externo 9: implementado en el 9% de nuestra base de usuarios (seleccionado al azar) para verificar defectos.
5. Externo 90: implementado en el 90% restante de usuarios.
6. Hospedado: implementado en el entorno hospedado.

En cada etapa, se cerrará la sesión para pasar al siguiente repositorio en caso de que se informen problemas.

Mis preguntas a la comunidad son:

1. ¿Alguien ha intentado algo como esto antes?
2. ¿Alguien puede ver una desventaja de este tipo de procedimiento?
3. ¿Hay una mejor manera?

En general, me encanta el enfoque. Los problemas de piratería no se pueden contrarrestar de todos modos, ya sea a través de la distribución tradicional o automatizada, y puede evitar los inconvenientes de un esquema de licencia.

Puede tener problemas con las selecciones aleatorias. ¿Se elige a un cliente para que sea uno de los primeros en adoptarlo durante toda su relación comercial? Si no es así, ¿cómo se puede realizar una degradación de 1 externo a 9 externo?

¿Ha pensado en la licencia general y la protección del tipo de teléfono residencial para su software?

El problema que veo aquí (sin ninguna licencia) es que puedo pagar por un mes, detener y luego seguir ejecutando esta versión. Claro que es viejo, pero es gratis. Esta escapatoria será explotada por al menos algunas personas

Si ya tiene licencia, simplemente tenga repositorios simples sin protección con el software que requiere verificar la licencia antes de ejecutar

No sé lo suficiente sobre su software y / o la naturaleza de sus clientes, pero en muchos lugares las actualizaciones no se instalan sin ser probadas. Muchas compañías usan una clave de licencia que expirará. Permítales descargar la actualización e iniciarla manualmente. Las actualizaciones automáticas son convenientes, pero a veces a los usuarios no les gustan las sorpresas.

Eche un vistazo al marco de Sparkle para OS X, hace algo muy similar al mecanismo de actualización de Chrome, pero proporciona comentarios de los usuarios para que puedan omitir la actualización o hacerlo más tarde. Me han actualizado las aplicaciones y he cambiado la funcionalidad que necesitaba tal como estaba, siempre es mejor preguntar al menos al usuario.

Sin embargo, me gusta la idea adecuada, tiene sentido hacerlo de esa manera, es simple y muy, muy bien probada en este momento.

Sé de una compañía que está haciendo casi exactamente lo que has descrito. (Menos niveles de los que ha descrito, y no sé cómo se están autenticando).

El mayor problema que tenían es que algunos clientes bloquean el acceso a Internet desde sus dispositivos. Eso significa que esos clientes simplemente están bloqueados a la versión que instalaron. Quizás eso está bien. Creo que discutieron la apertura de las reglas de firewall con algunos de esos clientes. Otros acaban de actualizarse manualmente.

Si tuviera que hacerlo, lo haría en función de la dirección IP. Entonces, cuando vienen a descargar, su dirección IP debe estar en la lista permitida para conectarse a ese servidor; de lo contrario, no pueden descargar. Es una mierda si no tienen una IP dedicada, pero es improbable por lo que parece que estás hablando si está basado en un servidor si es para estaciones de trabajo, entonces es mejor que los configures con su propio servidor apt interno y luego las descargas una copia a través de cron job o algo por ftp y así sucesivamente una vez a la semana y luego hay estaciones de trabajo descargadas desde allí realmente hasta usted.

Este es un buen enfoque experimentado.

Algunas trampas a considerar:

• Es posible que no siempre desee ir al 1 por ciento, 9 por ciento, 90 por ciento. Es posible que sus clientes no sean homogéneos, lo que significa que es posible que desee comenzar a especializarse, por ejemplo, por región, por tipo de dispositivo, etc., en cuyo caso una distribución en 1, 9, 90 por ciento a nivel mundial ya no tiene sentido.

• Tener un único repositorio para el 90 por ciento de sus usuarios introduce puntos de acceso : ese servidor experimentará la mayor parte de las solicitudes, lo que significa que será el primero en morir en caso de un aumento del tráfico, lo que provocará una interrupción en el 90 por ciento de sus usuarios. La redundancia ayuda, por supuesto, pero eso introduce más gastos en general.

• Es posible que tenga un flujo de trabajo donde ciertas características estén listas para su distribución al 90 por ciento de todos los usuarios, pero una actualización global hará que las características no estén listas para que la adopción del 90 por ciento llegue a la producción, introduciendo cuellos de botella en su flujo de trabajo de desarrollo. Una distribución fija no podrá manejar estos problemas de manera efectiva, lo que le obligará a manejar esto a nivel de aplicación.

Una forma de corregir esto es manteniendo varias copias de los repositorios de producción en diferentes servidores, coloque un equilibrador de carga configurable frente a él y luego actualice cuidadosamente sus repositorios de producción de forma gradual. En otras palabras, trate todos los repositorios como si finalmente quisieran ser los mismos, pero configure el tráfico para que el porcentaje de usuarios que leen desde un servidor sea cambiable.

El beneficio es que puede configurar la distribución de solicitudes a voluntad utilizando su equilibrador de carga, puede escalar horizontalmente mejor (todos sus servidores pueden comenzar a servir el mismo repositorio proporcionalmente si todas las características están listas para una adopción del 100 por ciento) y, dependiendo de cómo El flujo de trabajo del equipo y su necesidad de actualizaciones específicas de la región, eventualmente puede permitir que ciertas funciones estén disponibles de inmediato sin preocuparse por las otras funciones.