構建託管/ 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多個版本的軟件是不謹慎的，因此需要平衡限制所支持版本的數量，並且有一個貶低策略來推動客戶使用最新版本的產品。