Система «горячего» обновления ПО
По роду своей деятельности столкнулся со следующей задачей. Есть море пользователей, которые эксплуатируют постоянно изменяющийся софт. Приложения не требуют особой инсталляции, но их не мало, часть пользователей сидят на терминальных серверах и, самое главное, используют приложения для контроля за технологическими процессами производства.
Последняя фраза означает, что обновить приложение сразу у всех без длительного и ответственного процесса согласования отключений практически не возможно. Т.е. пользователя нужно уведомить о возможности обновиться, но момент лучше чтоб он выбрал сам, когда ему это сделать удобней исходя из режимов работы оборудования и т.д. Вроде бы классическая схема автоматизированного обновления ПО. Так, да не так! Тонкие клиенты упомянуты не зря. Один пользователь терминального сервера не имеет права решить за всех. Можно под каждого пользователя использовать свой исполняемый файл и прочее (мы ведь помним, что особенная инсталляция не требуется — в 99% случаев нужно что-то скопировать и что-то заменить исправленным). Но мне кажется это не красивым, к тому же одновременная работа с одним комплектом файлов (исполняемых и конфигурационных) разным пользователям не возбраняется.
Далее мне бы хотелось описать идею, которую пытаюсь реализовать, а в ответ «послушать» мнения уважаемых читателей. Это, как говорится, раз. А два — может есть готовые решения (алгоритмы) о которых мне не известно. Еще одно уточнение на разработчиков обновляемого ПО я практически не могу повлиять, т.е. их ПО само по себе, а система обновлений сама по себе.
Логическая группировка
Очевидно, что настройки обновляемого ПО для разных групп пользователей могут отличаться. Пусть у нас m типов ПО. Для каждого типа ПО создаем n самодостаточных конфигураций в зависимости от производственных потребностей. Называем эти конфигурации профилями их у нас m x n.
Источники обновлений
Имеем FTP-сервера (в общем случае их может быть много). На этих узлах имеем m x n URL (при необходимости, с разграничением прав доступа). По URL имеем набор директорий и служебный файл, несущий информацию о последнем обновлении: название профиля (для контроля), имя директории с обновлением, версия, тип обновления (поверх или с предварительной зачисткой), комментарий для пользователя.
Алгоритм работы демона на стороне клиента
Имеем перечень профилей для конкретной машины (ПК, терм. сервера), который прописан в конфигурационном файле демона (я службу назвал UHUD, будем ее и дальше так называть). В этом ответственном файле к каждому профилю отнесен URL из предыдущего пункта с явками и паролями, путь к локальному размещению профиля. В директории профиля имеем две служебные поддиректории и файл конфигурации с данными о версиях поддиректорий (об этом дальше), количестве занимающих эти папки клиентов (две подпапки — два значения).
Во время Ч, UHUD последовательно обходит профили и сверяет версию на FTP URL с локальными версиями служебных поддиректорий профиля. Если версия на сервере старше версии любой из поддиректорий — нужно обновляться. Это возможно только если на директории с самой старой версией не висят пользователи. Если можем, то обновляемся с учетом уже упоминавшегося типа обновления. В любом случае, поддиректория зачищается. Если тип обновления — «поверх», то из второй поддиректории копируется содержимое, а на нее «накатываются» данные с FTP, иначе — просто льем с сервера обновление. Ставим отметку о версии обновленной поддиректории в файле профиля.
С чем работает пользователь
Не упомянутый ранее важный момент заключается в том, что обновляемое ПО должно уметь работать с относительными путями (поскольку заранее не известно в какую поддиректорию попадем).
Пользователь запускает не исполняемый файл обновленного ПО, а клиентское приложение UHUD, дергающее, согласно настройкам профиля, нужную (старшую) версию (увеличивая счетчик клиентов к выбранной поддиректории) и прячущееся с глаз. Далее, это служебное ПО перепроверяет файл профиля и, при необходимости, предлагает пользователю переключиться на версию постарше, оставляя выбор времени, когда это сделать, за пользователем.
PS 1 Сознательно опущены моменты обработки ошибок, прав доступа на уровне файловой системы, совместной работы с конфигурационными файлами. При реализации стараюсь учесть, но расписывать не стал, чтоб не перегружать текст.
PS 2 Демон пишу на Qt с использованием qt-solutions. Теоретически должна получиться кросплатформенность, но пока тестирую только на Windows 7 (что имею на домашнем ноуте).