наверняка кто-то сталкивался с такой проблемой, есть большое количество клиентов пользующихся одни продуктом, обновлять его руками крайне муторно, по этому необходима система автоматического обновления, уже достаточно давно планирую такую структуру, но все время чего-то не хватает, может кто уже реализововал или просто есть идеи по принципу организации подобной работу... из требований: 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 пусть содержит инфу о всех версия, вот апдейтер пусть парсит его и все, выполняет нужные действия для своей версии
На сервере лежит файл в котором указана последняя версия. + файл в котором указаны все файлы программы и их md5 мы сравниваем чего не хватает докачиваем.
Убедительно попрошу отвечающих предварительно ознакомится с темой! тут уже раз 5 звучит один и тот же совет, еще раз повторюсь что необходимо обновлять некоторым клиентам дополительные модули и необходимо предусмотреть обновлечение через версию, пока все идеи по реализации описаны в моем посте чуть выше, если Вы с ними не согласны и готовы предложить лучше - буду Вам благодарен, с меня +
Посмотри на любые релизы любой мало-мальски распространенной системы: кроме самой новой версии всегда выпускаются апдейты ко всем ранее существовавшим поднимающие версию до current. Таким образом осуществить будет проще всего: клиент обращается к серверу обновлений и говорит свою версию, на что сервер выдает список подходящих для нее обновлений, а дальше - что ставить, а что нет решает юзверь. Обновления пофайлово не происходят никогда. Обновляется полностью модуль, поэтому всю цмс нужно разделить на N-ное их количество в независимом друг от друга исполнении. Так будет проще при реализации, да и конфликтов сможешь избежать. Придется вести учет версий всех модулей в движке, ага. Такое проще всего будет реализовать, если ты используешь при разработке SVN или CVS. Тебе нужно будет лишь просмотреть список изменений межу версиями и оформить в виде обновленных файлов. По поводу крона. Многие, в том числе и булка(vbulletin) используют метод псевдо image-cron'а, когда в тело страницы встраивается картинка, src которой указывает на cron.php, который и выполняет все необходимые действия. Как пример реализации систем обновлений можешь глянуть bitrix и umicms. Линки не даю - на варезниках полно. Еще можешь глянуть это же в TYPO3 (http://typo3.org), но в их коде черт ногу сломит.
спасибо на счет групп и модулей вместо одиночных файлов здравая мысль, а вот на счет апдейтов с текущей до максимальной пока еще размышляю, может всетаик стоит сделать поэтапно, в конце концов трафика всеравно мизерный