Как правильно обновлять приложение ?

Доброго времени суток! У меня есть приложение на C++, но столкнулся с такой проблемой, как правильно обновлять приложение ? Сейчас приложение при каждом запуске шлет на сервер запрос с версией, если версия старая, то приложение скачивает с ftp сервера архив с обновлениями, после чего приложение закрывается и запускает не большое приложение на pyhton, которое распаковывает этот архив. В архиве обновления содержатся только те файлы, которые нужно обновить. Проблема в том, что если у пользователя будет первая версия, а обновлений уже больше 50 будет, то приложению придется качать 50 архивов, а потом их распаковывать. Так вот вопрос, как лучше организовать обновление? Стоит ли хранить обновления в архивах на сервере или есть какой то другой способ? Спасибо.

0

Kostay17, вы можете хранить бинарную дельту для каждой из вышедших версий с самой последней. Например, у вас есть три версии, 1.0, 2.0, 3.0.
Пока последняя версия 3.0, вы можете хранить следующие файлы на сервере:
для версии у пользователя 1.0 = дельта между 1.0 и 3.0
для версии у пользователя 2.0 = дельта между 2.0 и 3.0.
При выходе версии 4.0. Реестр на сервере переписывается следующим образом:
для версии у пользователя 1.0 = дельта между 1.0 и 4.0
для версии у пользователя 2.0 = дельта между 2.0 и 4.0.
для версии у пользователя 3.0 = дельта между 3.0 и 4.0.

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

Дельту можно считать от архива (или установочного пакета). Чтобы схема работала после установки оригинальный установочный пакет должен быть сохранен где-то в каталоге приложения, чтобы потом к нему можно было применить дельту при обновлении.

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

3

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

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

Сообщение от Kostay17 Сейчас приложение при каждом запуске шлет на сервер запрос с версией, если версия старая, то приложение скачивает с ftp сервера архив с обновлениями

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

2

DrOffset, при 10 версиях получаем 45 архивов. И далее квадратично.
Я делаю так. При запросе обновления (именно при запросе!) скачиваю последний архив, распаковываю, смотрю на свежие (моложе существующих у юзера) файлы. Если таковые есть - их заменяю.
В общем, так как указал уважаемый COKPOWEHEU. Имхо, вполне разумно.

0

Байт, можно не сравнивать, просто принудительно заменять все exe и dll . Только файлы БД и настроек не трогать

Добавлено через 1 минуту
и как показала практика, нужно делать бэкап всех файлов - и заменяемые, и БД, и настройки. Но это часто уже на грани фантастики

1

Сообщение от Алексей1153 можно не сравнивать, просто принудительно заменять

Может быть....

Сообщение от Алексей1153 все exe и dll

Ну, у меня там не только они. Есть ряд "системных" файлов (в смысле моего приложения) Впрочем, о чем речь едет - понятно

Сообщение от Алексей1153 Только файлы БД и настроек не трогать

Безусловно! Все, к чему мог приложить руку пользователь - я уже не касаюсь.

Сообщение от Алексей1153 нужно делать бэкап всех файлов

Частично делаю. Однократно можно вернуться. Пытался сделать многократный откат, но это да, головная боль великая. Отложил идею до лучших времен.

0

Сообщение от Алексей1153 Только файлы БД и настроек не трогать

БД вообще не должны входить в дистрибутив.
А для конфигов рекомендуется встраивать конвертер из старого формата в новый. Причем старый сохранять с суффиксом .old или что-то в этом роде.

0

Сообщение от Байт получаем 45 архивов

При 10 версиях получаем 9 архивов, откуда вы взяли 45?
Да и это не архивы. Это разница между архивами, она обычно гораздо меньше.

Добавлено через 12 минут
Байт, а, я понял. Вы подумали, что я предлагаю на сервере хранить абсолютно все дельты между всеми версиями? Это совершенно не так, я такого не предлагал. На сервере всегда лежит самая последняя разница между вышедшими версиями и самой последней на данный момент. Это всегда на единицу меньше, чем общее число версий. Кроме того, разница на весь пакет - это меньше, чем разница между в версиями в файлах, т.к. сами файлы тоже, скорее всего, будут по большей части одинаковые. Если вы в библиотеку DLL, добавили всего одну функцию, то большая часть этой библиотеки останется одинаковой и в дельту не войдет. Поэтому то, что предлагаю я, позволит:
1) Обновляться пользователю с любой версии до самой последней в один этап (это требование задал ТС в стартовом посте).
2) Экономить место сервера, чтобы обеспечить первый пункт.

0

Сообщение от DrOffset Кроме того, разница на весь пакет - это меньше, чем разница между в версиями в файлах, т.к. сами файлы тоже, скорее всего, будут по большей части одинаковые.

Где-то слышал, что подобный подход применялся в какой-то системе контроля версий. И после накопления определенного количества таких икрементальных правок накапливались ошибки, что со временем делало применение очередного патча просто невозможным.
Поэтому в средах, где применяются инерементальные обновления, все равно время от времени создаются эталонные сборки.
Но важнее даже другое. Так ли уж велико преимущество от такого способа против простого скачивания новой версии полностью? Обновление - не настолько частая операция чтобы раз в полгода выкачать больший объем.
Собственно, на практике именно так и делают. В репозитории лежит самая свежая версия. Плюс последние версии необходимых библиотек, если их нет в репозитории ОС, плюс ресурсы (их тоже часто хранят отдельным пакетом). Иногда хранят не только последний тестовый релиз, но и, скажем, LTS, куда добавляют безопасность, а не свистелки.

0

COKPOWEHEU, он используется менеджерах пакетов linux дистрибутивов, например.

Сообщение от COKPOWEHEU Так ли уж велико преимущество

Это для меня неправильный вопрос. Я же не знаю, что у ТС за программа. Так что оценивает преимущество пусть он, а я лишь дал вариант.

0

Сообщение от DrOffset для версии у пользователя 1.0 = дельта между 1.0 и 3.0

Сообщение от DrOffset используется менеджерах пакетов linux дистрибутивов, например.

продукты, у которых мажор различается - не совместимы жеж.
или в линуксах не используется каноничное: мажор.минор.патч.расширение ?

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

минор - расширение апи.
гарантируется обратная совместимость.
всегда можно накатить.

мажор - кардинальное изменение в апи, которое нарушает обратную совместимость.
по пусти: принципиально новый продукт.

грубо говоря, обновить игрушку с версии 1 до версии 2 означает:
опционально снести всю первую часть.
и выполнить полную установку 2 части.

1

Сообщение от hoggy или в линуксах не используется каноничное: мажор.минор.патч.расширение ?

Используется.

Сообщение от hoggy для версии у пользователя 1.0 = дельта между 1.0 и 3.0

Это не имеет отношения к

Сообщение от hoggy продукты, у которых мажор различается - не совместимы жеж.

это просто пример. С тем же успехом могли быть просто a, b, c версии.

0

Сообщение от DrOffset это просто пример.

в твоём просто примере:

Сообщение от DrOffset 1.0

1.0 - это разве не мажор.минор?

или ты в своём примере просто забил на формат версиннирования?

0

Сообщение от hoggy продукты, у которых мажор различается - не совместимы жеж. или в линуксах не используется каноничное: мажор.минор.патч.расширение ?

В то же время - эта фича, если говорить о linux, в общем-то не привязана к совместимости приложений разных версий. Она просто модифицирует установку используя разницу, для новых файлов, которых, например, не было - просто будет разница 100%. Т.е. если кто-то захочет использовать ее между мажорными версиями - ничто ему не помешает.

Добавлено через 35 секунд

Сообщение от hoggy 1.0 - это разве не мажор.минор?

Нет.

Сообщение от hoggy или ты в своём примере просто забил на формат версиннирования?

Да, забил. Непринципиально потому что.

1

Сообщение от DrOffset В то же время - эта фича, если говорить о linux, в общем-то не привязана к совместимости приложений разных версий. Она просто модифицирует установку используя разницу, для новых файлов, которых, например, не было - просто будет разница 100%. Т.е. если кто-то захочет использовать ее между мажорными версиями - ничто ему не помешает.

не уверен, что правильно понял послание.

особенно часть:

Сообщение от DrOffset Т.е. если кто-то захочет использовать ее между мажорными версиями - ничто ему не помешает.

0

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

Добавлено через 11 минут
я тут предложил упрощенный вариант на самом деле. Например в linux ему не нужны архивы, чтобы строить разницу. Он может разобраться с приложением прямо в установленном виде. А возможно это потому, что есть индекс всех устанавливаемых файлов в пакете (опять же из-за стандартизированности самого процесса установки), который можно использовать как индекс архива.

1

Сообщение от DrOffset я тут предложил упрощенный вариант на самом деле. Например в linux ему не нужны архивы, чтобы строить разницу. Он может разобраться с приложением прямо в установленном виде. А возможно это потому, что есть индекс всех устанавливаемых файлов в пакете (опять же из-за стандартизированности самого процесса установки), который можно использовать как индекс архива.

в моей практике есть такая проблема:

допустим есть версия 1.0.0
эта версия работает с бд, которая так же имеет версию 1.0.0

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

таким образом обновление с 1.0.0 до 1.1.0 предполагает миграцию с бд 1.0.0 до 1.1.0
обязательно присутствует возможность отката.

если на бою вылезет какой то баг, нужно будет срочно откатывать базу данных.

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

далее, проходит какое то время, реализуются новые фичи.
и выходит новые обновление: уже с 1.1.0 до 1.2.0
ну и так далее по нарастающей, допустим до 1.10.0

и вот тут вылезает инженерная сложность:
у нас есть уже готовые, и проверенные временем процедуры пошагового обновления:
с 1.0.0 до 1.1.0, далее с 1.1.0 до 1.2.0, и тд. до самой последней версии.

эти процедуры возникли естейственным образом в процессе развития продукта.

то есть, мы без проблем можем сделать вот так:

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

но есть проблема:

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

если же сделать как ты предлагаешь:

Сообщение от DrOffset для версии у пользователя 1.0 = дельта между 1.0 и 4.0

тогда помимо уже проделанной работы,
придется дополнительно реализовывать миграцию:
1.0.0 ---> 1.1.0
1.0.0 ---> 1.2.0
1.0.0 ---> 1.3.0

затем тоже самое:
1.1.0 ---> 1.1.0
1.1.0 ---> 1.2.0
1.1.0 ---> 1.3.0

и тд.

это - ахренительно дофига работы.
каждую такую дельту нужно ещё протестировать и тд, и тп.

0

Сообщение от hoggy это - ахренительно дофига работы. каждую такую дельту нужно ещё протестировать и тд, и тп.

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

Добавлено через 2 минуты

Сообщение от DrOffset не любое приложение хорошо ляжет в эту систему

Именно поэтому, кстати, далеко не все пакеты в linux обновляются через эту систему. Для некоторых пакетов этой опции нет.

0

Сообщение от DrOffset Мне кажется, что и без примеров понятно, что не любое приложение хорошо ляжет в эту систему.

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

в реальном мире "обновление ПО" - это в первую очередь процедура миграции накопленных данных на новый софт.
и вот есть ли какие то практики, как это лучше всего делать - вот это интересный вопрос.

0

hoggy, я бы сказал, что довольно мало приложений в реальном мире умеют решать проблему обновления через несколько версий с сохранением данных. Независимо от способа обновления. Разработчики либо оставляют форматы данных максимально совместимым, иногда довольно сильно для этого извращаясь. Либо просто ломают к черту все. Максимум кто-нибудь напишет конвертер, который будет отдельным продуктом по сути. Почему-то вспомнилась Paradox`овская игра Crusader Kings (и Europa, кстати, тоже), где лучше вообще не обновлять версию пока не закончил кампанию, потому что файлы сохраненной игры от старой версии с вероятностью 40% будут вызывать падение приложения. И для игр это вообще довольно-таки типично.

Опять же, я не знаю что ты вкладываешь в понятие "тривиальные случаи", но есть довольно много приложений, которым не требуются какие-то форматы с критически важными данными для пользователя. Новая версия - новые данные.

Опять же, экспертизу делать я не нанимался. Поэтому я просто дал вариант, а дальше уж пусть сам смотрит. Я могу подискутировать только на тему откровенно неправильного понимания концепции (вроде того, что было в #4), или чтобы уточнить информацию. Если ты хочешь сделать экспертизу для ТС, это твое право

0