有料ソフトウェア更新のためのAptリポジトリの使用

毎週または毎月更新される可能性がある、ホストされた/オンサイトのWebアプリケーションのソフトウェア更新を配布する方法を決定しようとしています。オンサイト製品を使用しているお客様に手動での更新について心配する必要はありません。GoogleChromeから自動的にダウンロードしてインストールするだけです。Ubuntuとインストールおよび構成されたソフトウェアを含むOVFファイルを提供することを計画しています。

ソフトウェアの分散方法について最初に考えたのは、鍵を使用してSSH経由でアクセスされる6つのAptリポジトリ/チャネル（現時点ではどちらが良いかわからない）を作成することです。そのため、顧客がサブスクリプションを更新しない場合は、アカウントを無効にできます。 ：

1. ベータ-パッケージに重大な欠陥がないかどうかを確認するためにテストデータで内部的に使用されます。
2. 内部-パッケージの欠陥をチェックするためにライブデータで内部的に使用されます（ドッグフード段階）。
3. 外部1-ユーザーベースの1％に展開（ランダムに選択）して欠陥をチェックします。
4. 外部9-ユーザーベースの9％（ランダムに選択）に展開され、欠陥をチェックします。
5. 外部90-残りの90％のユーザーに展開されます。
6. ホスト-ホストされた環境にデプロイされます。

問題が報告された場合、次のリポジトリに移動するために、各段階でサインオフします。

コミュニティへの私の質問は次のとおりです。

1. 誰かが以前にこのようなことを試しましたか？
2. 誰もがこのタイプの手順のマイナス面を見ることができますか？
3. もっと良い方法はありますか？

全体として、私はこのアプローチが大好きです。いずれにせよ、著作権侵害の問題は、従来の配布や自動化を超えて対処することはできず、ライセンススキームの不便さを回避できます。

ランダム選択で問題が発生する可能性があります。顧客は、ビジネス関係の全期間にわたってアーリーアダプターになるように選択されていますか？そうでない場合、外部1から外部9へのダウングレードはどのように実現できますか？

ソフトウェアの一般的なライセンスとフォーンホームタイプの保護について考えましたか？

ここに表示される問題（ライセンスなし）は、1か月分を支払い、停止して、このバージョンで実行し続けることができるということです。確かに古いですが、無料です。この抜け穴は少なくとも一部の人々によって悪用されます

すでにライセンスを取得している場合は、実行する前にライセンスを確認する必要があるソフトウェアを備えた、保護されていない単純なリポジトリを用意してください

私はあなたのソフトウェアや顧客の性質について十分に知りませんが、多くの場所で更新はテストされなければインストールされません。多くの企業では、タイムアウトになるライセンスキーを使用しています。更新をダウンロードして手動で開始できるようにします。自動更新は便利ですが、ユーザーがサプライズを好まない場合もあります。

OS X用のSparkleフレームワークを見てください。これはChromeの更新メカニズムと非常によく似ていますが、ユーザーフィードバックを提供して、更新をスキップしたり後で実行したりできるようにします。アプリケーションを更新し、必要な機能を変更しました。少なくともユーザーに尋ねるのが常に最善です。

私は適切なアイデアが好きですが、そのようにするのは理にかなっています。シンプルで、この時点では本当に十分にテストされています。

私はあなたが説明したことをほぼ正確に行っている会社を知っています。（あなたが説明したよりも少ない層、そしてそれらがどのように認証されているのか私は知りません。）

彼らが抱えていた最大の問題は、一部の顧客がアプライアンスからのインターネットアクセスをブロックしていることです。つまり、それらの顧客は、インストールしたバージョンに制限されます。多分それは大丈夫です。ファイアウォールルールを開放することについて、それらの顧客と話し合ったと思います。その他は手動でアップグレードしたばかりです。

もし私がそれをするなら、私はIPアドレスに基づいてそれをするでしょう。そのため、ダウンロードするときに、そのサーバーに接続するには、IPアドレスが許可リストに含まれている必要があります。そうしないと、ダウンロードできません。彼らが専用のIPを持っていない場合は面倒ですが、それがワークステーション用である場合、それがサーバーベースである場合、あなたが話しているように聞こえる可能性は低いので、独自のaptサーバーを使用してセットアップし、ダウンロードすることをお勧めします。 cronジョブまたはFTP経由のコピーなどで週に1回コピーし、そこからワークステーションがダウンロードされます。

これは熟練したアプローチです。

考慮すべきいくつかの落とし穴：

• 常に1パ​​ーセント、9パーセント、90パーセントに行きたいとは限りません。顧客が同質ではない可能性があります。つまり、地域やデバイスの種類などで専門化を開始したい場合があります。その場合、世界全体での1、9、90％の分布は意味をなさなくなります。

• ユーザーの90％に単一のリポジトリがあると、ホットスポットが発生します。そのサーバーは大量のリクエストを経験するため、トラフィックの急増が発生すると最初にサーバーが停止し、ユーザーの90％が停止します。もちろん、冗長性は役立ちますが、全体としてより多くの費用がかかります。

• 特定の機能をすべてのユーザーの90％に配布する準備ができているワークフローがあるかもしれませんが、グローバルな更新により、90％を採用する準備ができていない機能が本番環境にヒットし、開発ワークフローにボトルネックが生じます。固定ディストリビューションではこれらの問題を効果的に処理できず、アプリケーションレベルでこれを処理する必要があります。

これを修正する方法は、異なるサーバーに本番リポジトリの複数のコピーを保持し、その前に構成可能なロードバランサーを配置してから、本番リポジトリを段階的に慎重に段階的に更新することです。つまり、すべてのリポジトリを最終的には同じにしたいものとして扱いますが、サーバーから読み取るユーザーの割合が変更できるようにトラフィックを構成します。

利点は、ロードバランサーを使用して自由にリクエストの分散を構成できること、水平方向に適切にスケーリングできること（すべての機能が100％の導入に対応できる場合、すべてのサーバーが同じレポに比例してサービスを開始できること）、そしてチームのワークフローは、地域固有の更新の必要性に応じて、他の機能を気にすることなく、特定の機能をすぐに利用できるようにすることができます。