5

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

  • www.AcmeCalculator.com将提供带有 Acme 标志的计算器，以及他们创造的平淡的企业风格。
  • www.HellzCalc.com将为计算器提供一些地狱天使骑自行车的标志和他们创建的黑色、血红色主题。

你推出了 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。

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

4

3 回答 3

4

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

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

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

于 2012-12-10T17:45:22.943 回答
0

与其拥有并行的定制版本，不如实现一个可供所有客户访问的可配置版本。

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

于 2011-02-13T21:27:16.230 回答
0

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

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

https://www.slideshare.net/TorryHarris/soa-serviceversioningbestpractices

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

于 2017-03-14T16:25:23.263 回答