При создавании РАЗМЕЩЕННОЙ/SAAS приложения, как Вы управляете несколькими версиями, когда настройки клиентом позволяются? [закрытый]

Закрытый. Этот вопрос должен быть более сфокусирован. Это в настоящее время не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, таким образом, он фокусируется на одной проблеме только путем редактирования этого сообщения.

Закрытый 2 года назад.

Давайте предположим, что Вы создаете приложение Калькулятора. Вы позволите клиентам настраивать этот Калькулятор со своими собственными логотипами и таблицами стилей CSS. Клиенты укажут на свои домены на Ваш размещенный Калькулятор, и приложение подаст корректную тему для каждого клиента. Например:

www.AcmeCalculator.com подаст Калькулятор с логотипом Высшей точки и мягкий корпоративный стиль, который они создали.
www.HellzCalc.com будет сервер Калькулятор с некоторыми байкерскими знаками Ангелов ада и черной, кроваво-красной темой, которую они создали.

Вы выставили Калькулятор 1.0, и все записали их стили для работы над этой версией.

В следующем месяце Вы готовы выпустить Калькулятор 1.1, который добавил новую опцию, скажем, "Научный Режим", который потребовал, чтобы Вы добавили некоторый новый UI - HTML в этом примере - компоненты. Это означает, выставляете ли Вы 1.1, Вы повредите некоторые стили своего клиента.

Лучшее решение, которое я предложил, состоит в том, что Вы поддерживаете несколько версий в рабочем состоянии своего приложения. Например:

www.AcmeCalculator.com решает к Вашему серверу приложений, который проверяет, что Высшая точка версии в настоящее время включена, и вперед на www.AcmeCalculator.com/1.0
www.HellzCalc.com решает к Вашему серверу приложений, который замечает, что они работают на новых 1,1 версиях, так как они вошли в обновленный их CSS для работы над новой версией и нажали кнопку "Finish Upgrade" или что бы то ни было, таким образом, они перенаправляются на "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, когда никакой (приложение) клиенты оставляют.

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

задан Animesh 10 January 2012 в 02:05

0 ответов

Другие вопросы по тегам:

versioning release-management hosted-app saas

При создавании РАЗМЕЩЕННОЙ/SAAS приложения, как Вы управляете несколькими версиями, когда настройки клиентом позволяются? [закрытый]

0 ответов

Похожие вопросы: