Каковы лучшие практики для самообновления приложений PHP + MySQL?

Question

Это довольно стандартная практика для самообновления настольных приложений. На Mac каждая не-Apple программа, которая использует Sparkle в моей книге, - это мгновенный выигрыш. Для разработчиков Windows это уже обсуждалось подробно . Я еще не нашел информацию о самообновляющихся веб-приложениях, и надеюсь, вы сможете помочь.

Я создаю веб-приложение, которое должно быть установлено как Wordpress или Drupal - распакуйте его в каталог, перейдите на страницу установки, и оно готово к работе. Чтобы обеспечить широкую совместимость с сервером, меня попросили использовать PHP и MySQL - это ** MP? В любом случае, он должен быть широко кроссплатформенным. Для контекста, это в основном унифицированное приложение обмена сообщениями для малого бизнеса. Это не другая платформа CMS, подумайте, веб-почта.

Я хочу знать о самообновляющихся веб-приложениях. Прежде всего, (1) это плохая идея? Начиная с Wordpress 2.7, автоматическое обновление представляет собой единственную кнопку, что кажется простым, и все же я могу представить себе множество способов, как это может пойти ужасно, ужасно неправильно. Кроме того, разве идея о том, что веб-файлы доступны для записи веб-процессом, не является дырой в безопасности?

(2) Стоит ли время разработки? Вероятно, в мире миллионы установок WP, поэтому, вероятно, команде WP понадобилось время, чтобы упростить процесс и сэкономить миллионы человеко-часов по всему миру. Я могу только представить несколько тысяч установок моего программного обеспечения - стоит ли самообновление здания, потраченное на затраты времени, или я могу предположить, что пользователи, достаточно опытные для загрузки и установки веб-программного обеспечения, могут в первую очередь пройти контрольный список обновления? *

Если это не катастрофа безопасности или трата времени, то (3) я ищу предложения от любого, кто делал это раньше. Вы храните таблицу версий в своей базе данных? Как вы управляете обновлениями БД? Какой метод вы используете для отката частичного обновления в контексте самообновляющегося веб-приложения? Разве использование слоя ORM облегчало или усложняло? Вы держите дельту изменений в версии или вы просто выбрасываете все это каждый раз?

Я ценю ваши мысли по этому поводу.

Answer 1

Честно говоря, это действительно зависит от вашей базы пользователей. Есть множество PHP-приложений, которые не обновляются автоматически. Их пользователи либо достаточно технически, чтобы справиться с процессом обновления, либо просто не обновляются.

Я делаю два шага:

1) Серьезно спросите себя, что, вероятно, действительно понадобится вашим пользователям. Будет ли самообновление достаточным стимулом для принятия, чтобы оправдать дополнительную работу? Если вы уверены, что ответ - да, просто сделайте это.

Поскольку вы спрашиваете здесь, я думаю, вы еще не знаете. В этом случае я ставлю цель шаг 2:

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

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

Answer 2

Да, это была бы функция безопасности, если бы PHP вышел и переписал свои файлы из какого-то места в Интернете без предупреждения. Нет никакой гарантии, что сервер правильно подключается к вашему серверу обновлений (он может загрузить чей-то код, созданный кем-то другим, если произошло отравление DNS) - предоставляя кому-то еще доступ к данным вашего клиента. Поэтому цифровая подпись будет важна.

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

Остается один вопрос (я действительно не знаю ответа): может ли PHP перезаписать файлы, если они используются в данный момент (например, нужно ли обновлять сам файл update.php)? Стоит проверить.

Answer 3

В последнее время я думал об этом в связи с изменениями схемы базы данных. В данный момент я копаюсь в WordPress, чтобы увидеть, как они обрабатывали изменения базы данных между ревизиями. Вот что я нашел до сих пор:

$wp_db_version загружается с wp-includes/version.php. Эта переменная соответствует номеру ревизии Subversion и обновляется при изменении wp-admin/includes/schema.php. (Возможно, через ловушку? Я не уверен.) Когда загружается wp-admin/admin.php, опция WordPress с именем db_version считывается из базы данных. Если это число не равно $wp_db_version, загружается wp-admin/upgrade.php.

wp-admin/includes/upgrade.php включает функцию под названием dbDelta(). dbDelta() сканирует $wp_queries (строка запросов SQL, которая создаст самую последнюю схему базы данных с нуля) и сравнивает ее со схемой в базе данных, изменяя таблицы по мере необходимости, чтобы схема была обновлена .

upgrade.php затем запускает функцию с именем upgrade_all(), которая запускает определенные функции upgrade_NNN(), если $wp_db_version меньше целевых значений. (т.е. upgrade_250(), обновление WordPress 2.5.0 будет запущено, если версия базы данных меньше 7499.) Каждая из этих функций запускает свои собственные процедуры переноса данных и заполнения, некоторые из которых вызываются во время начальной настройки базы данных. скрипт. Хорошо сокращает дубликаты кода.

Итак, это один из способов сделать это.

Answer 4

Я бы посоветовал вам упаковать ваше приложение с pear и , настроившим канал . Затем ваши пользователи могут обновить приложение через стандартный интерфейс (груша). Он не полностью автоматический (если пользователи не используют какую-то автоматизацию, работающую на вершине груши), но он является стандартным, поэтому любой системный администратор может его поддерживать.

Answer 5

Полагаю, вы уже исключили это, но вы можете разместить его в качестве службы. (Вспомните wordpress.com)

Answer 6

Только мои 2 цента: я бы посчитал самообновляющееся приложение в моей CMS дырой в безопасности, поэтому, если вы решите закодировать эту функцию, вам следует рассмотреть возможность реализации различных уровней этого поведения:

• Автоматически обновлять
• Проверить наличие обновлений и уведомить
• Отключить

Answer 7

Я думаю, что ваш лучший вариант - это механизм проверки обновлений, который будет уведомлять администратора об обновлении

Как вы упомянули, существует ряд потенциальных проблем безопасности. Из-за одних я бы предложил не делать этого. Вместо этого попробуйте создать довольно умный скрипт обновления.