Comments 7
UFO just landed and posted this here
У нас хранятся патчи на последние N релизов к последнему.
Например есть версии 1.11, 1.12, 1.15 и для них всех есть патчи до 1.18.
Есть мысли по-поводу интеллектуальной генерации на основе статистики запросов от клиентов.
Схема 1.11->1.12->1.15->1.18 не очень подходит, т.к. средний размер патча 7мб. Четыре таких патча это почти программа.
В качестве контейнера был выбран zip, внутри которого есть файлы/патчи и манифест, описывающий что делать. Работает отлично.
Например есть версии 1.11, 1.12, 1.15 и для них всех есть патчи до 1.18.
Есть мысли по-поводу интеллектуальной генерации на основе статистики запросов от клиентов.
Схема 1.11->1.12->1.15->1.18 не очень подходит, т.к. средний размер патча 7мб. Четыре таких патча это почти программа.
В качестве контейнера был выбран zip, внутри которого есть файлы/патчи и манифест, описывающий что делать. Работает отлично.
Да, я думаю это знакомая схема для многих. Мы тоже долгое время работали со своим велосипедом на Rar-Sfx. Работало и работало хорошо до тех пор пока не потребовался откат. Да и писать манифесты… ммм… смотря какие, конечно.
PatchWiz это делает сам. К тому же патч умеет хранить не весь файл для обновления, а только его измененные части (!), что может прилично уменьшить его объем (но мы этим не пользуемся по разным причинам).
То что я описал в этой статье — это только база, во второй статье я опишу наш подход, он сильно облегчает эту задачу.
PatchWiz это делает сам. К тому же патч умеет хранить не весь файл для обновления, а только его измененные части (!), что может прилично уменьшить его объем (но мы этим не пользуемся по разным причинам).
То что я описал в этой статье — это только база, во второй статье я опишу наш подход, он сильно облегчает эту задачу.
Я наверное как-то не так выразился :)
У нас своя система апдейта для продуктов.
Клиент обращается на апи со своей версией и получает ответ о том нужно ли обновиться и где взять апдейт.
Само обновление завернуто в zip(контейнер) и содержит новые файлы по сравнению с прошлым релизом(для них патч сгенерировать нельзя, они только-только появились), а также патчи(bsdiff).
Манифест также лежит внутри контейнера и служит для валидации конечного результата, хранения списка действий. Например, вот этот файл из контейнера нужно положить туда-то, этот файл использовать в качестве патча для такого-то файла. Если грубо, то операции patch, copy, delete, rename. После каждого такого действия проверяется sha256 получившегося файла и сраанивается с информацией в манифесте.
Писать руками ничего не нужно, выпуск релиза, как и деплой это почти наажтие одной кнопки.
У нас своя система апдейта для продуктов.
Клиент обращается на апи со своей версией и получает ответ о том нужно ли обновиться и где взять апдейт.
Само обновление завернуто в zip(контейнер) и содержит новые файлы по сравнению с прошлым релизом(для них патч сгенерировать нельзя, они только-только появились), а также патчи(bsdiff).
Манифест также лежит внутри контейнера и служит для валидации конечного результата, хранения списка действий. Например, вот этот файл из контейнера нужно положить туда-то, этот файл использовать в качестве патча для такого-то файла. Если грубо, то операции patch, copy, delete, rename. После каждого такого действия проверяется sha256 получившегося файла и сраанивается с информацией в манифесте.
Писать руками ничего не нужно, выпуск релиза, как и деплой это почти наажтие одной кнопки.
Все это понятно и прекрасно, только я не понял этого:
А как? Может тогда это тема новой статьи?
Писать руками ничего не нужно
А как? Может тогда это тема новой статьи?
Да делов то :)
Есть система апдейтов(что-то типа омахи), есть формат обновлений.
На сервере строятся пакеты апдейтов от прошлых релизов к актуальному, затем доставляются пользователям.
Писать руками что-то, чтобы апдейт попал до пользователя действительно не нужно. Достаточно создать новый релиз и инициировать деплой(сначала на тестовые площадки, потом на продакшн).
Если что-то конкретное интересует — спрашивайте, я отвечу :) Деплой и штуку, которая генерирует пакеты(те контейнеры с манифестами) писал я. Апдейтер писал другой человек, но я в курсе дел.
Есть система апдейтов(что-то типа омахи), есть формат обновлений.
На сервере строятся пакеты апдейтов от прошлых релизов к актуальному, затем доставляются пользователям.
Писать руками что-то, чтобы апдейт попал до пользователя действительно не нужно. Достаточно создать новый релиз и инициировать деплой(сначала на тестовые площадки, потом на продакшн).
Если что-то конкретное интересует — спрашивайте, я отвечу :) Деплой и штуку, которая генерирует пакеты(те контейнеры с манифестами) писал я. Апдейтер писал другой человек, но я в курсе дел.
Sign up to leave a comment.
Создание patch’ей на Wix при помощи PatchWiz