ホストされた/ SAASアプリケーションを構築する際に、顧客によるカスタマイズが許可されている場合、どのように複数のバージョンを管理しますか？

Question

Calculatorアプリケーションを構築しているとしましょう。お客様は、独自のロゴやCSSスタイルシートを使用してこの電卓をカスタマイズすることができます。顧客は自分のドメインをホストしている電卓に向け、アプリケーションは各顧客の正しいテーマを提供します。たとえば：

• www.AcmeCalculator.comはアクメのロゴ、およびそれらが作成当たり障りのない企業のスタイルで電卓をアップに役立つだろう。
• www.HellzCalc.comは、いくつかのHell's Angelsバイカーのサインと、彼らが作成した黒赤血球のテーマを使って電卓のサーバーを構築します。

Calculator 1.0をプッシュしました。誰もがこのバージョンで作業するためのスタイルを書いています。

次の月に、新しい機能を追加したCalculator 1.1をリリースする準備が整いました。このサンプルでは新しいUI（HTML）を追加する必要がある「科学的モード」としましょう。つまり、1.1を押し出すと、顧客のスタイルの一部が壊れることになります。

最高の解決策は、アプリケーションの複数のバージョンを実行しておくことです。たとえば、次のように

• www.AcmeCalculator.com転送へのアクメが現在オンになっているバージョンをチェックあなたのアプリケーションサーバーに解決し、www.AcmeCalculator.com/1.0
• www.HellzCalc .comは、新しいバージョンで動作するように更新されたCSSを使用し、[アップグレードの完了]ボタンなどをクリックしてリダイレクトされるため、新しい1.1バージョンで実行されていることに気づいたアプリケーションサーバーに解決します"www.HellzCalc.com/1.1

このシステムの1つの問題は、アップグレードに投資することのない怠惰な顧客が必然的にいることです。あなたは、それぞれのバグを修正しようとしているうちに、200のバージョンを同時に実行しています。

1つの解決策は、毎月のホスティング料金の一部を使用して、最も古いバージョンを実行しているキューで常にクライアントを引き継ぎ、CSSを調整するデザイナーのグループになる「UI移行チーム」を採用することです最新のバージョンで動作することを検証します。これにより、Xバージョンのみを同時にサポートすることができます。ここで、Xは、UI移行チームにどれだけのお金を投資し、それらをスピードアップしたり遅くしたりするためのリソースを追加する機能です。

電卓1.0と1.1はデータベース1.0で動作しますが、電卓1.2はデータベース1.1などで動作します。バージョン名のスキーマを追加するだけで、同様の "データ移行チーム"スキーマ1.0からスキーマ1.1にデータを移動し、最後にスキーマ1.0を削除します。

私はこのタイプの問題が以前に起きたと確信しています。他の人がそれをどのように解決したのかを見たいと思います。おそらく、このための「ベストプラクティス」さえあります。

Answer 1

パラレルにカスタマイズされたバージョンを使用する代わりに、構成可能なバージョンをすべてのクライアントからアクセスして実装します。

コードを書くのが難しくなりますが、アプリケーションを起動して実行すると、新しいニーズが何を壊すのではなく、新しいニーズが何であるか心配する必要があります。

Answer 2

あなたが企業のスペースにいて、顧客がアプリの大幅なカスタマイズを必要とし、それに応じて料金を請求できるのでない限り、私はこれを避けます。あなたが発見しているように、これは製品管理の悪夢の氷山の一角です。 SaaSが普及した理由の1つは、さまざまなバージョンの異なるユーザーを管理することは非常に難しく、ユーザーにアップグレードさせるのは難しいということです。

これを数回（私はエンジニアではなくバックグラウンドでプロダクトマネージャーなので、エンジニアが実装する必要があるほど悪いと感じているかもしれません）、設定可能なパラメータがあることをお勧めします。多くの場合、このタイプの構成では追加料金を請求することができます。つまり、基本価格にはカスタマイズがほとんどまたはまったくなく、上位の層ではCSSのカスタマイズやブランディングなどが可能です。例については、JobScore.comを参照してください。このためにお金を請求する良い理由は、小規模企業が気にしないで支払うこともありませんが、大企業はこの機能を望んでおり、費用についてはあまり気にしません。 SaaS製品の成功のためには、このような価格プレミアムを取得することが不可欠です。ほとんどのSaaS企業は、収益の80％を自社製品の「エンタープライズ」バージョンから購入するため、それに応じて価格を設定する必要があります。あなたのトップティアが$ 99/moでWalMartがサインアップして会社全体で$ 99/moで使用している場合、あなたはテーブルの上にたくさん残っています。

とにかく、元の質問に戻る：文字通りあなたの会社を殺すことができる別のバージョンを許可しないでください。代わりに、構成/変数を提供してください。

Answer 3

ここでは、ソフトウェアサービスのバージョン管理のベストプラクティスで見つかった良い記事があります。あなたの質問にも同じことが当てはまると思います。基本的には、利用可能な2つのオプションと、それぞれの長所と短所を説明します。

1. ソフトウェアのさまざまなバージョンを維持します。
2. 1つのベースラインバージョンのソフトウェアを維持します。 http://www.thbs.com/thbs-insights/soa-service-versioning-best-practices

は、それはあなたがそのようなサポートしていない場合は、顧客を失うリスクがある（ソフトウェア製品の複数のバージョンをサポートすることは避けられないとなりますいくつかの点で、企業向けSaaSの製品を展開している間戦略）。このアプローチにはいくつかのメリットがありますが、必要に応じてAPIやサービスの大規模な書き換えをサポートしていますが、下位互換性の問題では悩まされません。しかし、ソフトウェアの200以上のバージョンを維持することは賢明ではないので、サポートされているバージョンの数を制限し、最新バージョンの製品に向けて顧客を嫌がる戦略をとる必要があります。