в качестве веб-дизайнеров у нас был хороший год 2011 с более чем 50 (разными) cms и другими приложениями, управляемыми php 5.2. У некоторых были настройки для ядра. Как кто-то обновляет такое количество приложений до php 5.3?
Задумывались ли разработчики php об этом? Многочисленные (популярные) функции просто обесцениваются, что приводит к большой работе таким людям, как мы.
Я действительно не знаю, как лучше всего продолжить.
Проблемы с вашими скриптами при обновлении до PHP 5.3/5.4:
5.3 и 5.4 не на 100% совместимы с обратной связью! Просто обновление до 5.3/5.4 может сделать ваше приложение совершенно нецелесообразным - и серьезно повредить данные базы данных (если вы используете функции/методы, которые сейчас нарушены).
Обновление до 5.3/5.4 может дать вам много УВЕДОМЛЕНИЙ, ПРЕДУПРЕЖДЕНИЙ и ОШИБКОВ. УВЕДОМЛЕНИЯ просто предупреждают вас о "плохом стиле программирования", в то время как предупреждения и ошибки могут и сделают ваше приложение непригодным. Вам придется переписать части вашего кода.
Наиболее заметная вещь в обновлениях для 5.3: PHP дает массу уведомлений из-за "переменных undefined", даже многие высокопрофессиональные инструменты долгое время не были готовы к использованию на PHP 5.3 (wordpress, несколько рамок, основные сценарии и т.д.). Вы можете переопределить эти сообщения, установив сообщение об ошибках в error_reporting (E_ALL ^ E_NOTICE); Но помните: это просто быстрое и грязное решение! Это плохой стиль для этого.
Официальные обратные списки несовместимости PHP 5.3/5.4 довольно длинные и перечислены много фатальных ошибок и массовые изменения в логике того, как несколько вещей работают, и многое исправляет ошибки, кстати (что также может изменить что некоторые вещи ведут себя).
Официальная сводка обратной совместимости 5.3: http://php.net/manual/en/migration53.incompatible.php
Официальный список обратной совместимости 5.4: http://php.net/manual/en/migration54.incompatible.php
Что заставляет меня задавать большой вопрос, согласно вашему первоначальному вопросу:
Нужно ли мне обновляться до новой версии PHP?
Когда у вас есть проект свободного времени и вы хотите быть современным, просто потому, что это приятно: сделайте это! Но если вы работаете в профессиональной среде, с клиентами, которые платят вам и абсолютно необходимо иметь свои сайты на 100% в Интернете, спросите себя, действительно ли это действительно нужно? Не делайте обновлений, если есть большие изменения в наличии НЕГАТИВНЫХ ЭФФЕКТОВ на вашем приложении, производительности, движении денежных средств или отношениях с клиентом. В плохих случаях PHP беспорядочно использует ваше приложение, и вы понимаете, что произошла большая ошибка через несколько месяцев (с базой данных, полной дубликатов и т.д.). Спросите себя: каковы профи для обновления? Каковы минусы? Это всегда время и деньги, поэтому не делайте то, что не нужно.
Мое личное мнение: НЕ ОБНОВЛЯЙТЕ ВАШЕГО PHP, ЕСЛИ ВЫ НЕ НУЖДАЕТЕ! ВСЕГДА ПРОЙДИТЕ ЭТО С ОКРУЖАЮЩЕЙ СРЕДОЙ, ЭТО РАЗРАБОТАЛО! ТОЛЬКО ОБНОВЛЕНИЕ, ЕСЛИ ВЫ ЗНАЕТЕ ТОЧНО, ПОЧЕМУ ВЫ ДЕЛАЕТЕ.
Как обновить несколько приложений php до более новых версий /PHP 5.3/5.4:
Стратегия миграции будет зависеть от качества и содержания самого источника, а также от архитектуры и рабочего процесса. Нет никакой "серебряной пули", чтобы заставить ее работать.
Вы автоматически обновляете все промежуточные сайты, запускаете все модульные тесты, и, если они все пройдут, выполните приемочные тесты. Исправьте проблемы, которые возникают, пока вы не пройдете весь тест. Тогда пусть ваши сотрудники QA убедитесь, что все действительно на 100% нормально. Весь этот процесс будет в основном выполняться вашей системой непрерывной интеграции.//
Когда все работает в промежуточной среде, вы удаляете каждый сайт для обслуживания, развертывания обновленного кода в рабочей среде, обновления программного обеспечения сервера и восстановления сайтов.
Поскольку ни одно из ваших программ не имеет каких-либо единиц/приемочных испытаний, не имеет актуальной спецификации или даже понятия непрерывной системы интеграции, вам придется сделать это нелегко:
'step 1' take a survey of different servers setups on which your projects
are deployed (if you have all project on single box with
virtual-hosts, you can skip this bit )
'step 2' find somewhere a computer, which can temporary act as local server
<foreach setup>
'step 3' install/configure this temporary server to be exactly like
the "setup"
<foreach project on that setup>
'step 4' BACKUP ALL THE STUFF
'step 5' copy the latest source and DB from the production server
'step 6' upgrade the software
'step 7' see what has *blown* up and fix what you can find
'step 8' pass to the QA team
'step 9' store the source
</endforeach project>
'step 10' take the server with this configuration down for maintenance
'step 11' upgrade software on the server
'step 12' deploy all the projects from this server
'step 13' prayer (optional)
<endforeach setup>
Это своего рода "краткая" версия. В основном вам придется проходить сервер за сервером, клонировать его локально, а затем обновлять, исправлять проекты. Затем обновите каждый сервер и включите исправленную версию. Надежда.
Клиенты не будут платить за это.
Поскольку у вас есть ~ 50 различных проектов, вам придется исследовать, даже если это стоит времени и денег. После такого анализа вы можете обнаружить, что для бизнеса было бы более целесообразно отметить большинство проектов как "наследие" и просто обновить сервер до последнего 5.2.x. Затем оставьте это в покое.
Конечно, даже если вы решите не модернизировать большинство проектов, будут некоторые, которые потребуют этого. В частности, проект с постоянными контрактами, которые создают постоянный поток доходов для компании.
Я бы рекомендовал начать покупать обновления этих проектов с наличными деньгами, потому что вам все равно придется. И затем из этого опыта вы можете рассчитать затраты для остальной части вашего "портфеля".
PHP 5.4 отсутствует (во время последнего редактирования, уже 5,5). Большинство компаний к концу этого года столкнутся с вопросом: "Пришло ли время начать использовать 5.4?". Скорее, немного позже. Рамки и CMS, которые вы используете, тоже имеют тенденцию получать обновления.
В нижней строке: ваша компания в целом должна начать исследовать способы оптимизации этого процесса.
А как насчет того, когда вы обновляетесь до функций PHP 5.5 и mysql_*, вы начинаете показывать предупреждения E_DEPRECATE? См. красный ящик в mysql_affected_rows(). Это не разовая вещь.
Возможно, было бы разумно инвестировать в реализацию лучшей стратегии развертывания (что-то, что предполагает модульные тесты и непрерывную интеграцию).
<суб > <rant>
Суб >
Помогли ли разработчики php об этом? Многочисленные (популярные) функции просто обесцениваются, что приводит к большой работе таким людям, как мы.
Функции и функциональные возможности, которые устарели, отмечены как таковые в документации на века. Например, уведомление, что ereg() и передающий объект по ссылке не должны использоваться, был там с тех пор, как я начал изучать PHP. Предупреждения об устаревании будут в основном влиять на кодовую базу PHP4 (в этом случае вы сомневаетесь в том, что вам неинтересно).
Я не вижу, как применяемые практики, которые были приняты в сообществе в течение многих лет, "вызывают много работы".
<суб > </rant>
Суб >
Во-первых, если ваши программы хранятся в пакетах (RPM, DEB и т.д.), установленных через систему управления пакетами (yum, apt-get и т.д.) с корректной настройкой информации о зависимостях.
Затем, имея правильную цепочку освобождения с шагом интеграции, который проверяет, нарушается ли код при обновлении зависимостей. Сервер CI, такой как Jenkins, может запускать ваши автоматизированные тесты и создавать пакеты для вас.
Если есть проблемы, они появляются быстро, и вы можете работать над их исправлением. Используйте свои обычные внутренние процессы для определения приоритетов и исправления ошибок (отмечая, что стоит сосредоточиться на всех ошибках, связанных с обновлением зависимостей в заданном пакете в виде пакета, а не с разбивкой усилий, работая над десятком параллельных программ).
Очевидно, что вам следует следовать предлагаемым методам обновления; другие ответы предоставляются им.
Существуют процедурные и процедурные шаги; У меня нет конкретных предложений, и на самом деле tereško ответ довольно хороший ИМХО
Но где необходимо изменить базовую базу кода, у вас может быть выбор:
В чисто ручном подходе вам необходимо обнаружить все типы несовместимостей (изменения языка, изменения каркаса, замену инфраструктуры,...), выяснить, как их исправить в целом, а затем при необходимости применить каждый тип исправления. Эта последняя часть действительно дорога, потому что она требует, чтобы вы изучали каждую строку кода и исправляли ее, если это неправильно.
Автоматическое изменение не может помочь в обнаружении проблем или общей разработке решений. Но как только вы выясните, как решить проблему, возможно, это поможет в применении этого решения во всех необходимых местах.
Что необходимо для каждой проблемы, это своего рода "если вы видите это в коде, измените его на это". Эта неофициальная идея может быть упакована как преобразование программы, формальные правила для модификации кода.
Моя компания предлагает инструмент, DMS Software Reengineering Toolkit, который является механизмом преобразования программ. Он может анализировать и преобразовывать многие типы исходных кодов компьютера с использованием специфичных для языка интерфейсов; у него есть PHP front end (parser/prettyprinter), подходящий для этой задачи. DMS был разработан для такого рода задач, поэтому часть его названия - "программный реинжиниринговый инструментарий". Мы использовали его для много более сложных реинжиниринговых задач.
Итак, идея состоит в том, чтобы упаковать необходимые изменения в виде программных преобразований и использовать такой инструмент, как DMS для их применения. Это будет попытка написать правила, которые устраняют проблемы в вашем коде, но как только DMS сможет применить эти правила надежно. Таким образом, вы инвестируете в первые несколько систем (чтобы настроить и настроить правила), чтобы обновить последние 48 нечетных результатов.
Это не панацея; вы не всегда можете легко написать преобразование для того, что хотите. Но когда у вас много изменений, и вы хотите сделать их по всему вашему коду, делать столько, сколько вы можете надежно с помощью инструмента, намного лучше, чем делать все вручную.
Я полагаю, что этот список: http://php.net/manual/en/migration53.incompatible.php - это все, о чем вам нужно беспокоиться.
Лучшим способом для продолжения будет следовать Руководство по перенастройке PHP 5.3 (а затем PHP 5.4).
Если вы используете альтернативный веб-сервер, например cherokee, вы можете использовать параллельные установки PHP. Если вы не можете этого сделать из-за ограничений установки в вашем os, вы всегда можете использовать chrooted среду и изменить порты вашего php-интерпретатора.
Если мне нужно обновить версию php, я добавлю второй домен на страницу e. г. updated.domain.com, который использует новую версию php. Обычные пользователи не будут видеть разницы. Но, к сожалению, это будет работать, только если вы работаете с относительными путями и без жестко закодированных доменов в ваших файлах.