Обзор:

Этот вопрос был первоначально задан, а затем закрыт на StackOverflow . Мы указали в мета , что здесь самое подходящее место для этого вопроса.

Этот вопрос помогает многим людям найти правильный способ оценки обновлений Magento.

Вопрос:

Мне интересно узнать, как вы измеряете необходимое время для обновления Magento? Я думаю, что большинству из вас было нелегко ответить на вопрос клиента: «Сколько времени займет модернизация моего магазина Magento?»

Обычно клиенту нужно услышать только номер, например: «Это займет X часов и будет стоить Y баксов».

Основная идея вопроса заключается в технической стороне и в том, что вы проверяете как разработчик, чтобы сделать свои собственные расчеты для обновлений Magento.

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

• Касается ли ядро ​​Magento?
• Касается ли схема БД Magento?
• Есть ли у нас противоречивые данные в БД?
• Сколько пользовательских расширений установлено в пуле локального кода и кода сообщества?
• Совместимы ли пользовательские расширения с последней версией Magento?
• Использовал ли разработчик темы файл local.xml для директив макета или просто скопировал файлы xml из base / default / layout в каталог макета пользовательской темы?
• Имеем ли мы устаревшие директивы макета / методы блока в файлах макета XML?
• Я разработал этот магазин Magento?

Считаете ли вы, что я что-то упускаю, и если да, хотели бы вы поделиться со мной и сообществом своими дополнительными баллами для контрольного списка?

Оценка обновления Magento - это процесс сбора информации об изменениях, примененных к установке, которую вы собираетесь обновлять, проверка того, могут ли эти изменения вызвать проблемы, и затем оценка того, сколько времени требуется для их обхода.

Все модификации можно в буквальном смысле разделить на неосновную и встроенную .

Неосновные модификации - это те, которые не будут перезаписаны при обновлении. Это сторонние расширения , основные файлы, помещенные в локальную область (app / code / local / Mage) и пользовательская тема .

Изменения в ядре применяются непосредственно к файлам ядра Magento (app / code / core), файлам локализации (app / locale / en_US), шаблонам ядра и некоторым вещам, таким как javascripts , внешним библиотекам, которые редко настраиваются, тем не менее, необходимо принимать во внимание ,

Неосновные модификации

Сторонние расширения

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

Первое, что нужно проверить, это то, что функциональность, предоставляемая расширением, еще не реализована в той версии Magento, которую вы обновляете. Например , некоторые расширения , например Yoast_CanonicalUrl, Mxperts_CustomerAddressили Fontis_Wysiwygбыли широко использованы в Magento 1.3.xx и старше , но в настоящее время являются частью основной функциональности Magento и больше не требуется.

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

Затем важно проверить совместимость каждого из оставшихся расширений с версией Magento, до которой вы обновляетесь. В случае, если некоторые расширения не совместимы, и нет аналогичных расширений, вам будет сложно выбрать, потерять ли некоторые функции или изменить существующие расширения, чтобы сделать их совместимыми.

Примечание. Не изменяйте стороннее расширение напрямую, а создайте новое расширение, которое расширит устаревшее расширение, а затем установите зависимость в загрузочном XML нового расширения.

После того, как все сделано, фактический анализ каждого из остальных расширений может быть предоставлен Он всегда должен начинаться с проверки etc/config.xmlфайла. Есть 3 вещи для поиска:

• Переписывание классов само по себе не является чистой техникой, но в некоторых случаях другого пути нет. Так что, если переписанный класс был изменен в новой версии Magento, это может стать потенциальной проблемой.
• Обновления макета с меньшей вероятностью вызовут проблемы с вашим обновлением, но, тем не менее, если расширение ссылается на блок, который устарел в более новой версии Magento, вам придется обойти это.
• Обновления SQL являются крайне недооцененным источником проблем во время обновлений. Эта проблема возникает, когда стороннее расширение создает внешний ключ, ссылающийся на какое-то поле в таблице Magento по умолчанию. В результате это поле заблокировано от изменений. И тогда, если собственный скрипт установки попытается обновить это поле, он молча завершится неудачей. После этого каждый следующий скрипт установки, ссылающийся на это поле, приведет к сбою вашего обновления.

Приложение / код / ​​местные / Mage

После того, как вы закончили со своими расширениями, пришло время взглянуть на ваш app/code/local/Mageкаталог. Здесь вы найдете измененные файлы ядра, перемещенные в localобласть видимости. Каждый из них, безусловно, будет стоить вам седых волос, потому что вы никогда не знаете (если не вы их туда положили), что там было изменено и по какой причине. Таким образом, вы должны сравнить каждый из них с источником и перенести добавленную функциональность в соответствующий файл новой версии.

Пользовательская тема

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

Модификации In-Core

В идеальном мире их нет. Но когда вы получили установку Magento после того, как она была нарушена сторонними разработчиками, которые предлагают много по дешевке, вы можете ожидать чего угодно. Таким образом, изменения в ядре - это те, которые будут перезаписаны в процессе обновления. В большинстве случаев это не приведет к ошибкам, но в результате вы потеряете функциональность, которая была добавлена ​​таким жестоким способом.

Единственный способ обнаружить изменения в ядре - сравнить все файлы вашей установки Magento с чистыми файлами той же версии. Я рекомендую делать это с помощью git. Почему? Просто потому, что он будет хорошо обрабатывать все новые строки и пробелы.

Даже если ваша установка Magento не входит в git, вы все равно можете скопировать свои файлы в отдельный каталог и затем запустить git init. Затем сделайте начальный коммит, скопируйте «чистые» файлы Magento и запустите git status. Вы получите что-то вроде этого:

Теперь в зависимости от количества измененных файлов вы можете запускать как git diffдля каждого файла, так и для всего пакета сразу. Это даст вам исчерпывающую информацию обо всех сделанных модификациях ядра. Если у вас есть какая-то git-визуализация, такая как phpStorm, вам намного проще:

Я предлагаю сделать git diff > changes.txtтак, чтобы у вас всегда был список изменений вручную.

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

Теперь я хотел бы дать несколько советов для реального обновления. Этот процесс хорошо документирован, поэтому я не буду писать, какие команды запускать и где нажимать. Однако я хочу сделать акцент на нескольких важных вещах:

• Мы предполагаем, что вы выполняете обновление в своей среде разработки. Запуск обновления на вашем производственном сервере - самоубийство.
• Не позволяйте им что-либо менять в процессе производства. Поставьте свой Magento под контроль версий или даже временно заблокируйте файлы от записи.
• Отключите все сторонние расширения, но обратите внимание, какие из них были изначально отключены, чтобы впоследствии их не включить.
• Проверьте, есть ли на сервере запущенный скрипт очистки Magento. В противном случае усечение всех таблиц , начиная с dataflow_*, log_*, report_*.
• Вернитесь к теме по умолчанию во время обновления.

После завершения обновления скрипт:

• Ссылка на changes.txtсделанные вами до миграции все внутренние модификации, которые действительно заслуживают миграции.
• Перенос app/code/local/Mageизменений, найденных до обновления.
• Один за другим включить сторонние расширения.
• Верните свою тему и всесторонне сравните результат с рабочим сервером.
• Развертывание на производстве, когда вы довольны результатом.

Заключение

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

Пост скриптум

В очень сложных случаях имеет смысл начать все заново с новой установки последней версии Magento и выполнить постепенную миграцию темы и функциональности вашего магазина. Это определенно займет время, но в итоге у вас будет здоровая система Magento с полным осознанием того, что происходит.

Вообще говоря, код Core никогда не должен затрагиваться при разработке. В Magento есть много механизмов, позволяющих обойти любые проблемы, даже внутренние ошибки. Тем не менее, есть и другие вопросы, на которые следует обратить внимание.

1. Переопределяют ли какие-либо сообщества или локальные модули основной код (можно искать в папке модулей <rewrite>, и это плохая практика, так как они действительно должны использовать ненавязчивый код, такой как события)
2. Magento пытается сохранить код обратно совместимым, но иногда код значительно меняется (его можно найти здесь ), если имеется множество несовместимых изменений, которые могут добавить к процессу.
3. Легко ли / возможно ли продублировать код в среде разработки. если это так, достаточно просто запустить обновление и тестирование.
4. Требуется ли обновление? Есть ли в новой версии функции, без которых клиент не может уйти? Любые проблемы с безопасностью (много раз Magento также предоставляет исправления)

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

Вот некоторые вещи, которые нужно иметь в виду:

• Проверьте, совместима ли тема (проверьте, нет ли обширного кодирования в файлах шаблонов - иногда это делают молодые разработчики)
• Проверьте, как хранятся носители (используют ли они CDN и т. Д.)
• Проверьте, есть ли специальные методы кэширования (APC Memcached и т. Д.)

Один из способов обработать этот тип клиентского запроса - выполнить оценку оценки.

Это влечет за собой сообщение клиенту, что вы потратите некоторое (оплачиваемое) время на его просмотр, и даст им более точные временные рамки / стоимость для выполнения проекта.

Путь по этому маршруту приносит пользу и вам, и клиенту.

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

Оценить обзор:

Фактическая оценка оценки будет выглядеть примерно так:

• Создать дамп живой базы данных и импортировать ее на компьютер разработчика
• Скопируйте файлы magento с их действующего компьютера на компьютер разработчика.
• Убедитесь, что все хорошо и работает
• Попробуйте выполнить обновление и проведите начальное тестирование, чтобы увидеть, что может сломаться

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

Мы сделали различные обновления для Magento CE, худшие из которых были от 1,3 до 1,7, что заняло у нас почти 4 полных дня. Первоначальная оценка составляла 1-2 дня. Я полагаю, что обновление с 1.x до 2.x будет таким же огромным мероприятием, и даже если основная команда предоставит инструменты миграции, было бы проще начать с нуля.

Я хочу добавить одну вещь к превосходным ответам, данным выше:

• Проверьте, имеет ли VCS и надлежащий процесс развертывания на месте.

Я не буду выполнять обновление без соответствующих процессов и возможности отступить, когда возникнут проблемы (даже больше, если я раньше не работал на сайте). Около 90% клиентов, обращающихся к нам за обновлением Magento (которые раньше не были нашими клиентами), имеют только живую среду без какого-либо тестирования / подготовки, VCS, что бы там ни было.

Интеграция с другими объектами - важная вещь, о которой нужно спросить. Это то, что вы, возможно, не сможете заметить, посмотрев на сайт - для клиентов характерно, например, то, что внутренние системы получают заказы через API Magento, и если вы не выполняете непрерывность этой интеграции при обновлении может попасть в беспорядок.

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