@Kostay17

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

0

@DrOffset

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

@COKPOWEHEU

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

2

Байт

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

0

Алексей1153

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

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

1

Байт

Может быть....
Ну, у меня там не только они. Есть ряд "системных" файлов (в смысле моего приложения) Впрочем, о чем речь едет - понятно
Безусловно! Все, к чему мог приложить руку пользователь - я уже не касаюсь.
Частично делаю. Однократно можно вернуться. Пытался сделать многократный откат, но это да, головная боль великая. Отложил идею до лучших времен.

0

@COKPOWEHEU

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

0

@DrOffset

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

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

0

@COKPOWEHEU

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

0

@DrOffset

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

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

0

@hoggy

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

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

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

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

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

1

@DrOffset

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

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

0

@hoggy

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

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

0

@DrOffset

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

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

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

1

@hoggy

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

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

0

@DrOffset

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

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

1

@hoggy

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

допустим есть версия 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, и тд. до самой последней версии.

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

то есть, мы без проблем можем сделать вот так:
но есть проблема:
если же сделать как ты предлагаешь:
тогда помимо уже проделанной работы,
придется дополнительно реализовывать миграцию:
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

@DrOffset

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

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

0

@hoggy

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

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

0

@DrOffset

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

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

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

0