假设您正在构建一个计算器应用程序。您将允许客户使用自己的徽标和 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。
我敢肯定这种类型的问题以前出现过,我想看看其他人是如何解决的。也许甚至有一个“最佳实践”。