Использование Apt Repository для платных обновлений программного обеспечения

Я пытаюсь определить способ распространения обновлений программного обеспечения для размещенного на сайте веб-приложения, которое может иметь еженедельные и / или ежемесячные обновления. Я не хочу, чтобы клиенты, использующие локальный продукт, беспокоились об его обновлении вручную, я просто хочу, чтобы он автоматически загружал и устанавливал Google Chrome. Я планирую предоставить файл OVF с Ubuntu и программным обеспечением, установленным и настроенным.

Моя первая мысль о том, как распространять программное обеспечение, - это создать шесть репозиториев / каналов Apt (не уверен, что будет лучше в данный момент), к которым будет обращаться через SSH с использованием ключей, поэтому, если клиент не продлит свою подписку, мы можем отключить его учетную запись. :

1. Бета-версия. Используется для проверки данных на наличие серьезных дефектов.
2. Внутренний - используется для внутренних данных при проверке упаковки на наличие дефектов (стадия выгула собак).
3. Внешний 1 - Развернут на 1% нашей пользовательской базы (выбран случайным образом) для проверки на наличие дефектов.
4. Внешний 9 - Развернут на 9% нашей пользовательской базы (выбран случайным образом) для проверки на наличие дефектов.
5. Внешний 90 - Развернуто на оставшиеся 90% пользователей.
6. Размещено - Развернуто в размещенной среде.

На каждом этапе потребуется подпись, чтобы перейти к следующему хранилищу в случае возникновения проблем.

Мои вопросы к сообществу:

1. Кто-нибудь пробовал что-то подобное раньше?
2. Кто-нибудь может увидеть обратную сторону этого типа процедуры?
3. Есть ли способ лучше?

В целом, я люблю подход. С проблемами пиратства в любом случае нельзя бороться, будь то традиционное распространение или автоматизация, и вы можете избежать неудобств схемы лицензирования.

Вы можете получить проблемы со случайным выбором. Выбран ли покупатель в качестве первопроходца на все время ваших деловых отношений? Если нет, то как можно осуществить понижение с внешнего 1 на внешний 9?

Задумывались ли вы об общем лицензировании и защите типа домашнего телефона для вашего программного обеспечения?

Проблема, которую я вижу здесь (без каких-либо лицензий), заключается в том, что я могу заплатить за месяц, остановиться, а потом просто продолжать работать с этой версией. Конечно, он старый, но бесплатный. Эта лазейка будет использоваться, по крайней мере, некоторыми людьми

Если у вас уже есть лицензия, то просто используйте простые незащищенные репозитории с программным обеспечением, требующим проверки лицензии перед запуском

Я недостаточно знаю о вашем программном обеспечении и / или характере ваших клиентов, но во многих местах обновления не устанавливаются без тестирования. Многие компании используют лицензионный ключ, срок действия которого истекает. Разрешить им загружать обновления и запускать вручную. Автообновления удобны, но иногда пользователям не нравятся сюрпризы.

Взгляните на платформу Sparkle для OS X, она очень похожа на механизм обновления Chrome, но обеспечивает обратную связь с пользователем, чтобы они могли пропустить обновление или сделать это позже. У меня были обновления приложений и изменения функциональности, которые мне были нужны, всегда лучше по крайней мере спросить пользователя.

Мне нравится подходящая идея, хотя, имеет смысл сделать это таким образом, это просто и действительно, очень хорошо проверено на данный момент.

Я знаю компанию, которая делает почти точно то, что вы описали. (Меньше уровней, чем вы описали, и я не знаю, как они аутентифицируются.)

Самая большая проблема, с которой они столкнулись, заключается в том, что некоторые клиенты блокируют доступ в Интернет со своего устройства. Это означает, что эти клиенты просто заблокированы версией, которую они установили. Может быть, это нормально. Я думаю, что они обсуждали правила открытия брандмауэра с некоторыми из этих клиентов. Другие просто обновляются вручную.

Если бы я сделал это, я бы сделал это на основе IP-адреса. Поэтому, когда они приходят, чтобы скачать их IP-адрес должен быть в списке разрешенных для подключения к этому серверу, в противном случае они не могут загрузить. Это отстой, если у них нет выделенного IP-адреса, но вряд ли из того, о чем вы говорите, если он основан на сервере, если он предназначен для рабочих станций, тогда вам лучше настроить их с помощью собственного сервера apt, а затем загружать его. копия через cron job или что-то через ftp и т. д. раз в неделю, а затем туда загружаются рабочие станции.

Это хороший опытный подход.

Некоторые подводные камни для рассмотрения:

• Вы можете не всегда хотеть идти 1 процент, 9 процентов, 90 процентов. Ваши клиенты могут быть неоднородными, то есть вы можете начать специализироваться, скажем, по регионам, по типу устройства и т. Д. В этом случае распределение на 1, 9, 90 процентов по всему миру больше не имеет смысла.

• Наличие единого репозитория для 90 процентов ваших пользователей представляет « горячую точку» - этот сервер будет обрабатывать большую часть запросов, что означает, что он умрет первым в случае скачка трафика, что приведет к отключению для 90 процентов ваших пользователей. Избыточность помогает, конечно, но в целом это увеличивает расходы.

• У вас может быть рабочий процесс, в котором определенные функции готовы для распространения среди 90 процентов всех пользователей, но глобальное обновление приведет к тому, что функции, не готовые к 90-процентному внедрению, попадут в производство, что приведет к появлению узких мест в вашем рабочем процессе разработчика. Фиксированный дистрибутив не сможет эффективно справиться с этими проблемами, что заставит вас справиться с этим на уровне приложения.

Это можно исправить путем хранения нескольких копий производственных репозиториев на разных серверах, размещения настраиваемого балансировщика нагрузки перед ним и последующего постепенного обновления производственных репозиториев. Другими словами, относитесь ко всем репозиториям как к тем, которые в итоге хотят быть одинаковыми, но настраивайте трафик так, чтобы процент пользователей, читающих с сервера, был изменяемым.

Преимущество заключается в том, что вы можете настроить распределение запросов по своему усмотрению, используя свой балансировщик нагрузки, вы можете лучше масштабировать по горизонтали (все ваши серверы могут начать обслуживать одно и то же хранилище пропорционально, если все функции готовы к 100-процентному принятию), и, в зависимости от того, как ваш Рабочий процесс команды и ваша потребность в обновлениях для конкретного региона, вы можете в конечном итоге позволить некоторые функции быть доступными сразу, не беспокоясь о других функциях.