Как я могу структурировать автоматическое обновление настольного приложения, когда у вас несколько версий сервера, с прерыванием изменений между версиями каждого сервера? - PullRequest
Новая
       47

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

0 голосов
/ 19 октября 2018

Структура: 

Server - Desktop Application

Я хотел бы иметь механизм автообновления в настольном приложении.Это может быть достигнуто с помощью таких вещей, как Squirel.Windows, и выходит за рамки этого вопроса.Еще одно замечание: у DesktopApp есть несколько вариантов для разных ОС (Mac и Windows).

Проблема в том, что сервер не всегда является последней версией.Например: 

Server.v1 - DesktopApp.v1
Server.v2 - DesktopApp.v1

Server.v1 и Server.v2 имеют различное поведение и критические изменения.Как структурировать автоматическое обновление в DesktopApp управляемым способом?

Версия сервера также может внезапно перейти на другую версию, например, с Server.v2 на Server.v1.Это вне нашего контроля.

ПРИМЕЧАНИЕ. Сервер не соответствует semver, поэтому младшие номера версий могут иметь серьезные изменения

Предложение 1)

Сделайте DesktopApp обратно совместимым, как это 

if(serverVersion == Server.v1) {
    MetodOfLogicThatWorksOnV1();
}; 
if(serverVersion >= Server.v2) {
    MetodOfLogicThatWorksOnV2();
};

Теперь я могу свободно обновлять DesktopApp.v1 столько раз, сколько я хочу, и он будет полностью обратно совместим.Все пользователи приложения Desktop используют последнюю версию.

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

Предложение 2)

Создание DesktopAppМеханик обновления знает, когда он должен понизить 

if(serverVersion == Server.v1) {
    DesktopApp.SelfUpdater.Update(v1);
};
if(serverVersion >= Server.v2) {
    DesktopApp.SelfUpdater.Update(latest);
};

Теперь пользователи получат разные версии DesktopApp в зависимости от того, к какой версии сервера они подключены.

Беспокойство: пользователям придется обновлять / понижать версиюв зависимости от версии.Будет сложно поддерживать эту логику обновления.Исправление ошибки теперь необходимо будет сделать как для DesktopApp.v1, так и для DesktopApp.v2

Предложение 3)

Создать 1 DesktopApp на версию сервера 

if(serverVersion != clientVersion) {
    DesktopApp.SelfUpdater.Update(serverVersion);
};

Это означает, чтоЯ знаю, что версия Сервера всегда будет предназначена для точной версии DesktopApp, которую я использую

Беспокойство: необходимо создать очень много версий DesktopApp, а исправления ошибок необходимо развернуть во многих версиях.

Вопрос:

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

Ответы [ 2 ]

0 голосов
/ 19 октября 2018

Вместо коммутатора у вас может быть интерфейс, который определяет ваши операции, и «традиционный» фабричный метод для создания экземпляра правильной реализации: 

IMyOperations GetMyOperationsFactory(){
  var version = Server.GetVersion()
  if (version == 1) return new MyOperationsV1();
  if (version == 2) return new MyOperationsV2();
  throw new InvalidOperationException("Server version " + version + " not supported");
}

Тогда вы по крайней мере изолируете поведение, зависящее от версии.Добавьте традиционную объектную ориентацию (наследование и еще много чего), если это выгодно.

0 голосов
/ 19 октября 2018

Если ваша организация контролирует как серверное, так и настольное приложение, лучшим решением будет дисциплина в разработке сервера.Вы должны прояснить, что частые несовместимые изменения в протоколе сервера добавляют работу для команды приложения.Один инструмент, который я (слегка) использовал, который может помочь в этом: Pact , который позволит вам «записывать» запросы и ожидаемые ответы клиента, а затем запускать их в качестве тестовых случаев на сервере без необходимостизавершите сквозную настройку теста.

Если вы управляете сервером, другой лучший вариант - это server , поддерживающий более старые версии протокола.Я не очень часто использую API , но его ссылка на API содержит список всех прошлых версий и список изменений, и старые и новые клиенты и серверы могут взаимодействовать.Docker также реализует ваш «вариант 1», где клиентский код может при необходимости перейти на более старую версию протокола.

В противном случае, с точки зрения пользователя, ваш вариант 1 является единственным хорошим.Приложение, которое обычно хочет нарушить ваш рабочий процесс и переустановить себя (вариант 2), быстро раздражает, но хуже, если приложение просто случайно перестает работать при обновлении сервера (вариант 3).Существуют также общие шаблоны развертывания, такие как «канареечные сборки», которые могут приводить к одновременной работе как старых, так и новых серверов, и для их поддержки клиентское приложение должно работать с обоими.

...