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

Question

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

• www.AcmeCalculator.com将成为了Acme的标志计算器，和他们创造了一个平淡无奇的企业风格。
• www.HellzCalc.com将服务器与一些地狱天使骑自行车的迹象和他们创造的黑色，血红色的主题计算器。

你已经推出了计算器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，最后在没有（应用）客户端被删除时删除模式1.0。

我确定这种类型的问题出现之前，我想看看其他人如何解决它。也许甚至有这样的“最佳实践”。

Answer 1

而不是具有平行定制版本，实现一个可配置版本由您的所有客户端访问。

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

Answer 2

除非您身处企业领域，您的客户需要对其应用程序进行重要定制，并且您可以对其进行相应的收费，否则我会避免这种情况。正如你所发现的，这是产品管理噩梦的冰山一角。 SaaS变得如此流行的原因之一是，管理不同版本的不同人员非常困难，而且很难让人们升级。我曾经做过几次这样的事情（我是背景的产品经理，不是工程师，所以我可能感觉到的痛苦几乎和工程师必须实现的一样糟糕），我会建议有可配置的参数。通常你可以为这种类型的配置收取额外的费用。也就是说，基本价格几乎没有定制，更高的层次允许CSS自定义，品牌等。请参阅JobScore.com的示例。为此收取资金的一个很好的理由是小公司不关心也不会付钱，但是大公司需要这个功能，而且不会在意成本。获得这种价格溢价对于成功的SaaS产品至关重要：大多数SaaS公司从其“企业”版产品中获得80％的收入，因此您需要相应地进行定价。如果您的最高级别为$ 99 /月，并且WalMart在整个公司内注册并以$ 99 /月的价格使用它，那么您将在桌面上留下很多东西。

无论如何，回到原来的问题：不允许不同的版本，这可能会从字面上杀死你的公司。相反，提供配置/变量。

Answer 3

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

1. 保持不同版本的软件。
2. 保持一个基准版本的软件。

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

虽然推出了一个企业的SAAS产品，在某些时候，它会成为一种必然，你支持你的软件产品的多个版本（在失去客户的风险，如果你不支持这样的战略）。这种方法有一些好处，值得注意的是，如果需要的话，它支持大量重写API /服务，而不会因向后兼容性问题而陷入困境。然而，维护200多个版本的软件是不谨慎的，因此需要平衡限制所支持版本的数量，并且有一个贬低策略来推动客户使用最新版本的产品。