Обзор:
Этот вопрос был первоначально задан, а затем закрыт на 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, до которой вы обновляетесь. В случае, если некоторые расширения не совместимы, и нет аналогичных расширений, вам будет сложно выбрать, потерять ли некоторые функции или изменить существующие расширения, чтобы сделать их совместимыми.
После того, как все сделано, фактический анализ каждого из остальных расширений может быть предоставлен Он всегда должен начинаться с проверки
etc/config.xml
файла. Есть 3 вещи для поиска:Приложение / код / местные / 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
так, чтобы у вас всегда был список изменений вручную.Имея список основных модификаций, вы можете оценить, что нужно перенести в новую версию и сколько времени потребуется для этого.
Теперь я хотел бы дать несколько советов для реального обновления. Этот процесс хорошо документирован, поэтому я не буду писать, какие команды запускать и где нажимать. Однако я хочу сделать акцент на нескольких важных вещах:
dataflow_*
,log_*
,report_*
.После завершения обновления скрипт:
changes.txt
сделанные вами до миграции все внутренние модификации, которые действительно заслуживают миграции.app/code/local/Mage
изменений, найденных до обновления.Заключение
Я знаю, что все это звучит страшно, но если вы регулярно обновляетесь, сохраняете свое ядро чистым и устанавливаете расширения только от поставщиков, которым вы действительно доверяете, и только если они вам действительно нужны, вы не столкнетесь с большинством трудностей, описанных в этой статье. Держите вашу Magento EcoSystem здоровой, и вы будете вознаграждены.
Пост скриптум
В очень сложных случаях имеет смысл начать все заново с новой установки последней версии Magento и выполнить постепенную миграцию темы и функциональности вашего магазина. Это определенно займет время, но в итоге у вас будет здоровая система Magento с полным осознанием того, что происходит.
источник
Вообще говоря, код Core никогда не должен затрагиваться при разработке. В Magento есть много механизмов, позволяющих обойти любые проблемы, даже внутренние ошибки. Тем не менее, есть и другие вопросы, на которые следует обратить внимание.
<rewrite>
, и это плохая практика, так как они действительно должны использовать ненавязчивый код, такой как события)Что касается шаблона, из предыдущего опыта я могу сказать, что он едва ломается, если разработчик не сходил с ума по кодированию шаблона (который в любом случае должен быть в блоках).
источник
Вот некоторые вещи, которые нужно иметь в виду:
Один из способов обработать этот тип клиентского запроса - выполнить оценку оценки.
Это влечет за собой сообщение клиенту, что вы потратите некоторое (оплачиваемое) время на его просмотр, и даст им более точные временные рамки / стоимость для выполнения проекта.
Путь по этому маршруту приносит пользу и вам, и клиенту.
Клиент, как правило, будет чувствовать себя более уверенно в вашей оценке и будет уважать ваши рекомендации, которые, в свою очередь, принесут вам пользу, уменьшив возможный стресс.
Оценить обзор:
Фактическая оценка оценки будет выглядеть примерно так:
Этот процесс должен занять в среднем два оплачиваемых часа, и даст вам много необходимой информации о системе под рукой.
источник
Мы сделали различные обновления для Magento CE, худшие из которых были от 1,3 до 1,7, что заняло у нас почти 4 полных дня. Первоначальная оценка составляла 1-2 дня. Я полагаю, что обновление с 1.x до 2.x будет таким же огромным мероприятием, и даже если основная команда предоставит инструменты миграции, было бы проще начать с нуля.
источник
Я хочу добавить одну вещь к превосходным ответам, данным выше:
Я не буду выполнять обновление без соответствующих процессов и возможности отступить, когда возникнут проблемы (даже больше, если я раньше не работал на сайте). Около 90% клиентов, обращающихся к нам за обновлением Magento (которые раньше не были нашими клиентами), имеют только живую среду без какого-либо тестирования / подготовки, VCS, что бы там ни было.
источник
Интеграция с другими объектами - важная вещь, о которой нужно спросить. Это то, что вы, возможно, не сможете заметить, посмотрев на сайт - для клиентов характерно, например, то, что внутренние системы получают заказы через API Magento, и если вы не выполняете непрерывность этой интеграции при обновлении может попасть в беспорядок.
Когда вы просматриваете компоненты, обратите внимание на те, которые общаются с другими системами - каждая из них будет тестовой, потому что вы не хотите случайно передавать тестовые данные в работающую систему. Часто существует тестовая конечная точка, которая использовалась первоначальными разработчиками, но у вас может не быть этой информации больше при обновлении.
источник