Просмотр полной версии : Система автоматического обновления
наверняка кто-то сталкивался с такой проблемой, есть большое количество клиентов пользующихся одни продуктом, обновлять его руками крайне муторно, по этому необходима система автоматического обновления, уже достаточно давно планирую такую структуру, но все время чего-то не хватает, может кто уже реализововал или просто есть идеи по принципу организации подобной работу...
из требований:
1) проверка наличия обновлений на удаленном сервере
2) получение списка файлов которые необходимо обновить (у разных клиентов набор файлов может различаться)
3) прием обновленных файлов (вот тут особенно интересует ваше мнение - каким протоколом пользоваться)
4) проверка целостности и в случае необходимости перезакачка
5) бекап старых файлов и подмена их новыми
Да хоть по http
Примитивно:
Апдейтер обращается к файлу на сервер, если файл пустой - обновления не требуются, если нет, требуются.
Допустим файл будет содержать ссылку на закачку и md5 сумму закачиваемого файла.
примерно так:
http://site.ru/update/prog.exe:md5
Апдейтер качает, сверяет сумму, если не сходится докачивать. Для разных версий, пусть парсит разные файлы на сервере
Бэкап старых файлов и запись новых отдельным процессом при перезапуске программы
это php приложение, проверка обновления предполагается не через cron а при заходе администратором в панель управления и начало закачки по его команде => гипотетически может получится, что клиент Х долгое время не посещающий панель управления будет вынужден обновляться с версии 1 на версию 3, так как провафлил обновление до 2 => тут надо как-то п умному придумать контроль версий, тем более что у разных клиентов список файлов может различаться (у кого-то установлены специальные уникальные плагины)
В случае если клиент пропустил апдейт, нужно продумывать не систему обновления, а структуру софта, чтобы не пришлось потом велосипед изобретать.
А принцип апдейта один и тот же в принципе, разницы нет, пхп или нет. И крон тут не нужен, не будет же каждый клиент себе крон настраивать.
Точно так же, допустим по кнопке "проверить обновления" скрипт парсит файл, и т.д.
заливает нужные файлы к себе в папку (можно архив с посчитанной суммой, проще), потом заменяет их на существующие с бэкапом.
на счет крона согласен, потому сразу от него отказался, а вот касательно пропуска апдейта и разных списков этот вопрос всееще открыт
Все это можно осушиствить на том же пхп.
Но вот проблеммма с конфигами как их обновлять ? все парсить ?
ну да это все и предполагается писать на пхп, а на счет конфигов - все настройки храню в БД
При каждом запуске программы чекать файл http://file.ru/update/version.ini
Где пишется версия новой проги..если не сходится с существующей, выполнять действия описанные выше
Isis это уже обсуждалось, открытые вопросы
1) как выполнять обновление через версию (предполагаю что стоит хранить инфу о всех версиях и последовательно обновлять к лиента с 1 до 3 предварительно обновив до 2)
2) как разным клиентам выдавать разные списки файлов для обновления
version.ini пусть содержит инфу о всех версия, вот апдейтер пусть парсит его и все, выполняет нужные действия для своей версии
ну да, наверное это самое верное решение и обновлять по ступенькам 1->2->3
На сервере лежит файл в котором указана последняя версия.
+ файл в котором указаны все файлы программы и их md5 мы сравниваем чего не хватает докачиваем.
Убедительно попрошу отвечающих предварительно ознакомится с темой! тут уже раз 5 звучит один и тот же совет, еще раз повторюсь что необходимо обновлять некоторым клиентам дополительные модули и необходимо предусмотреть обновлечение через версию, пока все идеи по реализации описаны в моем посте чуть выше, если Вы с ними не согласны и готовы предложить лучше - буду Вам благодарен, с меня +
Посмотри на любые релизы любой мало-мальски распространенной системы: кроме самой новой версии всегда выпускаются апдейты ко всем ранее существовавшим поднимающие версию до current.
Таким образом осуществить будет проще всего:
клиент обращается к серверу обновлений и говорит свою версию, на что сервер выдает список подходящих для нее обновлений, а дальше - что ставить, а что нет решает юзверь.
Обновления пофайлово не происходят никогда. Обновляется полностью модуль, поэтому всю цмс нужно разделить на N-ное их количество в независимом друг от друга исполнении. Так будет проще при реализации, да и конфликтов сможешь избежать. Придется вести учет версий всех модулей в движке, ага.
Такое проще всего будет реализовать, если ты используешь при разработке SVN или CVS. Тебе нужно будет лишь просмотреть список изменений межу версиями и оформить в виде обновленных файлов.
По поводу крона. Многие, в том числе и булка(vbulletin) используют метод псевдо image-cron'а, когда в тело страницы встраивается картинка, src которой указывает на cron.php, который и выполняет все необходимые действия.
Как пример реализации систем обновлений можешь глянуть bitrix и umicms. Линки не даю - на варезниках полно. Еще можешь глянуть это же в TYPO3 (http://typo3.org), но в их коде черт ногу сломит.
спасибо на счет групп и модулей вместо одиночных файлов здравая мысль, а вот на счет апдейтов с текущей до максимальной пока еще размышляю, может всетаик стоит сделать поэтапно, в конце концов трафика всеравно мизерный
vBulletin® v3.8.14, Copyright ©2000-2026, vBulletin Solutions, Inc. Перевод: zCarot