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

Question

关闭。这个问题需要更多 focused .它目前不接受答案。












想改进这个问题？更新问题，使其仅关注一个问题 editing this post .

5年前关闭。




Improve this question




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

www.AcmeCalculator.com 将提供带有 Acme 标志的计算器，以及他们创造的平淡的企业风格。

www.HellzCalc.com 将为计算器提供一些 hell 天使骑自行车的标志和他们创建的黑色、血红色主题。

你推出了 Calculator 1.0，每个人都编写了他们的样式来使用这个版本。

下个月你准备发布 Calculator 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 迁移团队中投入多少资金的函数，添加资源以加快或减慢它们的速度。

同样的想法也适用于数据库更改:Calculator 1.0 和 1.1 在数据库 1.0 上运行，但 Calculator 1.2 在数据库 1.1 上运行，等等。您可以添加带有版本名称的模式，并使用类似的“数据迁移团队”来移动数据架构 1.0 到架构 1.1，最终在没有(应用)客户端时删除架构 1.0。

我敢肯定这种类型的问题以前出现过，我想看看其他人是如何解决的。也许甚至有一个“最佳实践”。

Answer 1

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

这样做了几次(我是背景的产品经理，而不是工程师，所以我可能会感到与工程师必须实现的痛苦几乎一样严重)，我建议使用可配置的参数。通常，您可以为此类配置收取额外费用。也就是说，基本价格几乎没有定制，更高的层级允许 CSS 定制、品牌等。请参阅 JobScore.com 以获取示例。为此收费的一个很好的理由是，小公司不在乎也不会付钱，但大公司想要这个功能，不会那么在意成本。获得这种价格溢价对于成功的 SaaS 产品至关重要:大多数 SaaS 公司 80% 的收入来自其产品的“企业”版本，因此您需要相应地定价。如果您的顶级产品是 99 美元/月，而沃尔玛注册并在整个公司以 99 美元/月的价格使用它，那么您将在桌面上留下很多东西。

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