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

Question

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

Я создаю веб-приложение, предназначенное для установки как 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

Я полагаю, вы уже приняли это решение, но можете принять его как услугу. (Think wordpress.com)

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

Я думал об этом в последнее время в отношении изменения схемы базы данных. На данный момент я копаю в 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 7

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

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

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