使用Apt资料库进行付费软件更新

我正在尝试确定一种分发可能具有每周和/或每月更新的托管/站点Web应用程序软件更新的方法。我不希望使用现场产品的客户不必担心手动更新，而只希望它可以自动下载并安装Google Chrome。我打算提供一个包含Ubuntu和安装和配置的软件的OVF文件。

我关于如何分发软件的第一个想法是创建六个Apt存储库/通道（目前不确定哪个会更好），可以使用密钥通过SSH访问它，因此，如果客户不续订，我们可以禁用其帐户：

1. Beta-在测试数据内部使用，以检查包装是否存在重大缺陷。
2. 内部-内部用于实时数据以检查包装是否有缺陷（狗食阶段）。
3. 外部1-部署到我们用户群的1％（随机选择）以检查缺陷。
4. 外部9-部署到我们用户群的9％（随机选择）以检查缺陷。
5. 外部90-部署到其余90％的用户。
6. 托管-部署到托管环境。

如果报告了问题，则将在每个阶段进行签名以移入下一个存储库。

我对社区的问题是：

1. 有人曾尝试过类似的方法吗？
2. 谁能看到这种程序的弊端？
3. 有没有更好的办法？

总的来说，我喜欢这种方法。无论是通过传统分发还是通过自动分发，都无法解决盗版问题，并且您可以避免许可计划带来的不便。

您可能会在随机选择方面遇到问题。是否在整个业务关系的整个过程中都选择了客户作为早期采用者？如果没有，如何实现从外部1降级到外部9？

您是否考虑过软件的一般许可和电话家庭类型保护？

我在这里看到的问题（没有任何许可）是我可以支付一个月的费用，停下来，然后继续在此版本上运行。确定它是旧的，但它是免费的。至少有人会利用这个漏洞

如果您已经获得许可，则只需拥有简单的未受保护的存储库，并且该软件需要在运行之前检查许可

我对您的软件和/或客户的性质了解不足，但是在许多地方，未经测试就不会安装更新。许多公司使用的许可证密钥将超时。允许他们下载更新并手动启动。自动更新很方便，但有时用户不喜欢惊喜。

看一下OS X的Sparkle框架，它与Chrome更新机制的功能非常相似，但是会提供用户反馈，以便他们可以跳过更新或稍后进行更新。我已经对我的应用程序进行了更新，并按原样更改了我需要的功能，最好至少向用户询问。

我喜欢这样的想法，这样做很有意义，在这一点上它很简单，而且经过了很好的测试。

我知道一家公司所做的几乎与您描述的完全一样。（层数比您描述的少，我不知道它们如何进行身份验证。）

他们遇到的最大问题是某些客户阻止了他们设备的Internet访问。这意味着这些客户仅被锁定到他们安装的版本。也许很好。我认为他们与其中一些客户讨论了开放防火墙规则的问题。其他人只是手动升级。

如果我要这样做，我会根据IP地址来做。因此，当他们来下载其IP地址时，必须将其IP地址放在允许的列表中才能连接到该服务器，否则他们将无法下载。如果他们没有专用的ip，这很糟糕，但是听起来好像不太像您所说的是基于服务器的服务器（如果用于工作站），那么最好在内部使用自己的apt服务器进行设置，然后再进行下载通过cron作业或通过ftp进行的复制等，每周一次，然后在那里从那里实际下载工作站。

这是一个很好的经验方法。

需要考虑的一些陷阱：

• 您可能并不总是希望走1％，9％，90％。您的客户可能不是同质的，这意味着您可能想开始按区域，按设备类型等进行专业化，在这种情况下，以1％，9％，90％的比例进行全球分布已不再有意义。

• 为90％的用户拥有一个存储库会引入热点 -该服务器将遇到大量请求，这意味着它将在流量激增时首先消失，从而导致90％的用户中断。当然，冗余会有所帮助，但这会带来更多的费用。

• 您可能有一个工作流，其中某些功能已准备就绪，可以分发给所有用户的90％，但是全局更新将导致尚未准备好90％的功能投入生产，从而在开发工作流中引入了瓶颈。固定发行版将无法有效处理这些问题，从而迫使您在应用程序级别进行处理。

解决该问题的一种方法是，将生产仓库的多个副本保留在不同的服务器上，在其前面放置一个可配置的负载平衡器，然后逐步滚动地仔细更新生产仓库。换句话说，将所有存储库视作最终希望相同，但要配置流量，以便从服务器读取的用户百分比是可变的。

好处是您可以使用负载平衡器随意配置请求的分布，可以更好地横向扩展（如果所有功能都准备好100％可用，则所有服务器都可以按比例开始提供相同的存储库），并且取决于您的方式团队的工作流程是，并且您需要特定于区域的更新，因此您最终可以立即使用某些功能，而不必担心其他功能。