构建托管/ SAAS应用程序时，如果允许客户进行自定义，您如何管理多个版本？

Question

让我们假设您正在构建一个Calculator应用程序。您将允许客户使用自己的徽标和CSS样式表自定义此计算器。客户将其域名指向您的托管计算器，该应用程序将为每个客户提供正确的主题。例如：

• www.AcmeCalculator.com 将为计算器提供Acme徽标，以及他们创造的平淡企业风格。
• www.HellzCalc.com 将通过一些Hell's Angels骑车标志和他们创造的黑色血红主题为计算器提供服务。

你已经推出了计算器1.0，并且每个人都已经编写了他们的样式来处理这个版本。

下个月你准备发布计算器1.1，它增加了一个新功能，让我们说“科学模式”，它要求你添加一些新的UI - 本例中的HTML - 组件。这意味着如果您推出1.1，您将打破一些客户的风格。

我提出的最佳解决方案是保持应用程序的多个版本运行。例如：

• www.AcmeCalculator.com 解析为您的应用服务器，该服务器会检查Acme当前所使用的版本，然后转发到 www.AcmeCalculator.com/1.0
• www.HellzCalc.com 解析为您的应用服务器，注意到他们在新的1.1版本上运行，因为他们更新了他们的CSS以处理新版本并点击了“完成升级“按钮或其他任何内容，以便将它们重定向到” www.HellzCalc.com/1.1

这个系统的一个问题是，你不可避免地会有懒惰的客户，他们从不投资升级。你将会巧妙地运行200个版本，试图修复每个版本中的错误，基本上是疯了。

一种解决方案是使用每月托管费的一部分来雇用“UI迁移团队”，这将是一组设计师，他们唯一的工作就是不断地将客户端带入运行最旧版本的队列并调整他们的CSS和验证它们在最新版本上运行。这将允许您同时仅支持X版本，其中X是您在UI迁移团队中投入多少资金的函数，添加资源以加速或减慢它们。

同样的想法适用于数据库更改：计算器1.0和1.1在数据库1.0上运行，但计算器1.2在数据库1.1等上运行。您可以只添加具有版本名称的模式，并使用类似的“数据迁移团队”来将数据从模式1.0移动到模式1.1，最后在没有（app）客户端时删除模式1.0。

我确定此类问题已经出现过，我想看看其他人是如何解决的。也许甚至有一个“最佳实践”。

Answer 1

除非您在企业领域并且您的客户需要对其应用程序进行大量自定义，并且您可以相应地对其收费，否则我会避免这种情况。正如您所发现的那样，这是产品管理噩梦的冰山一角。 SaaS变得如此受欢迎的原因之一是，在不同版本上管理不同的人是非常困难的，并且很难让人们升级。

这样做了几次（我是背景的产品经理，而不是工程师，所以我可能觉得痛苦几乎和工程师必须实施的一样糟糕），我建议有可配置的参数。通常，您可以为此类配置收取额外费用。也就是说，基本价格几乎没有自定义，更高层级允许CSS自定义，品牌推广等。请参阅JobScore.com以获取示例。为此收费的一个很好的理由是，较小的公司不关心也不会付钱，但较大的公司需要这个功能，而不会关心成本。获得这种价格溢价对于成功的SaaS产品至关重要：大多数SaaS公司80％的收入来自其产品的“企业”版本，因此您需要相应定价。如果您的顶级价格为99美元/月，而WalMart在整个公司注册并以99美元/月的价格使用它，那么您就会离开桌面。

无论如何，回到最初的问题：不要允许不同的版本，这可能真的会杀死你的公司。相反，提供配置/变量。

Answer 2

不要使用并行自定义版本，而是实施所有客户端访问的可配置版本。

编写代码会给你带来更多麻烦，但是当你启动并运行你的应用程序时，你只需要担心你的新需求是什么，而不是那些新需求会破坏。

Answer 3

这是我在软件服务版本化最佳实践中发现的一篇好文章，我相信同样适用于您的问题。它基本上描述了两种可能的选择以及每种选择的优缺点。

1. 维护不同版本的软件。
2. 维护该软件的单个基线版本。

http://www.thbs.com/thbs-insights/soa-service-versioning-best-practices

在推出企业SAAS产品的同时，您将不可避免地支持您的软件产品的多个版本（如果您不支持此类策略，则有失去客户的风险）。这种方法有一些好处，特别是如果需要的话，它可以支持大量重写api / services，同时不会因向后兼容性问题而陷入困境。但是，维护200多个版本的软件是不明智的，因此需要平衡来限制支持的版本数量，并且还有一个弃用策略来推动客户使用最新版本的产品。