Лучшая практика для проведения обновления Magento?

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

1. получите себе чистую версию Magento, на которой вы сейчас находитесь, и не забудьте сделать ее сопоставимой. Или используйте существующее зеркало git magento (см. Подробнее http://blog.speedupmate.com/post/4063307705/magento-git-mirror )

2. создать мастер-репо на основе 1. здесь и иметь его под рукой

   Отвечая на вопрос: Ваша конечная цель – иметь чистое ядро ​​со всеми файлами в git, которые присутствуют в установочных файлах magento. Это необходимо, чтобы вы могли сравнить все с чистой установкой. Управление основными изменениями, core filetree (существующие, несуществующие, добавленные файлы). Вы можете обрабатывать свои исключения с помощью .gitignore (исключая медиа, кеш, все поля с областью сервера local.xml .htaccess). Мне легко перемещать основные файлы Magento в другой (не публичный) каталог (как описано здесь http://blog.speedupmate.com/post/9992573819/poor-mans-multisite-setup-for-magento ), и это будет дайте мне состояние кода, где .htaccess никогда не конфликтует при обновлении. Я также никогда не включаю средства управления версиями, кеш и все временные файлы, которые генерирует magento. Это гарантирует вам четкий путь при обновлении, так как вы можете отключить все для времени обновления. Сравнение кода позже даст вам объем вещей, которые вам нужны для обзора, и вы можете оценить, сколько времени вам потребуется, чтобы сравнить измененные части и перейти в режиме реального времени с обновлением.

3. теперь с вашим существующим сайтом и git config на месте (чтобы сделать его сопоставимым) выполните git init на вашей кодовой базе и добавьте все, чтобы git там, это перейдет по вашей конфигурации git и сделает каждый файл сопоставимым (те же новые строки, пробелы и т. д.), затем исправлять права на файлы, чтобы они были одинаковыми. После этого вы можете удалить папку .git со своего сайта, так как вы использовали только git, чтобы сопоставлять файлы.

   Спросите в комментариях: Дело в том, что git действительно работает для вас, как преобразование всех окончаний строк в стиль unix и игнорирование пробелов, вы можете игнорировать разрешения тоже теоретически, но это не полезно (форматирование здесь бит, так что \ представляет собой разрыв строки между командами

   git config core.autocrlf input \ git config core.eol lf \ git config apply.whitespace nowarn

   Теперь, если вы делаете git init и добавляете эти конфиги и добавляете все в git, то во время сдачи на сцену git заменит все ваши окончания окон и всю эту дерьмо на унифицированный и сопоставимый стиль. Обратите внимание, что стандарт кодирования zend предлагает окончание строк стиля Unix, однако вы также увидите файлы, в которых библиотека Zend не соответствует своим собственным стандартам. Ключевым моментом здесь является то, что вам нужно, чтобы ваши файлы были сопоставимыми, чтобы минимизировать нагрузку на diff, которую вы должны делать. Вы удалите папку .git после того, как git отформатировал все ваши плохие файлы установки для вас. Git используется только для автоматизации «создания сопоставимого процесса» на этом этапе, и ничего больше

4. проверьте свой тестовый репозиторий на основе вашего основного репо в 1. и проверьте ветку с версией, в которой вы сейчас находитесь, и назовите ее «testomething» или что вам нужно

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

   Спросите в комментариях: я обычно добавляю whitespace, игнорируя git config (доступна локальная или глобальная область), и пусть git обрабатывает это для меня. При работе в командах мы всегда соглашаемся на основе стандартов Zend: 4 пробела для вкладок, окончаний строк стиля Unix и переменных конфигурации git, упомянутых в 3. И если скрипты сборки задействованы, мы делаем форматирование кода и проверку с помощью фиксации фиксации.

6. перемещайте все файлы в пустой каталог (обратите внимание, что вы удалили каталог .git с вашего существующего сайта, сделав его сопоставимым) с вашей установки figled up magento (теперь они сопоставимы) и запустите git status > changes.txt . В этом файле перечислены все различия, которые у вас есть, любой новый файл, какой-либо удаленный, переименованный и т. Д. Файл, который у вас есть на вашей «f cked up installation», против чистого кода Magento, который вы сейчас используете.

   Объясняя, основываясь на комментариях: обычно я делаю git status --porcelain

7. у вас есть файл .gitignore, чтобы помочь вам отменить local.xml var / * или каждый файл / каталог, который вам не нужен для управления версиями, а также .DS_Store, .Thumbs.db и ваши идеи создали файлы проекта из git. Вам не нужны все медиа и кешированные файлы и файлы, которые различаются на каждом сервере в вашем управлении версиями.

Оттуда вы должны тщательно просмотреть этот список и на основе этого списка вы должны:

• переместите каждое основное изменение в app / code / local / и проверьте измененный файл в его исходное состояние (сохраните скопированный файл и отмените изменения в ядре с помощью git checkout filename )
• перемещать каждый измененный основной шаблон и файл макета в свою собственную папку тем и проверять измененный файл на его исходное состояние
• вернуть или перенести .htaccess, изменить или решить, нужно ли сохранять или отбрасывать

Теперь вы все еще в плохом состоянии, но вы сейчас:

• на основе чистого ядра
• на основе дерева версий в отдельном ветви

Теперь вы можете воспользоваться версией контролируемой, сопоставимой и отдельной ветвью на основе вашей основной ветки, в которой есть сменные версии Magento. Поэтому давайте попробуем обновиться, вот ключевые моменты успеха на 100%.

1. первым шагом было бы отключить все «дерьмо», которые вы теперь разделили на app / code / local / Mage /, и для разделения темы. Если ваше ядро ​​ясно и темы могут быть отключены, у вас нет настраиваемого кода, мешающего процессу обновления. Итак, отключайте:

   • все локальные расширения и пользовательские расширения сообщества, перемещая их из приложения / etc / modules / в папку temp, пусть это будет приложение / etc / inactive /
   • отключить настраиваемые темы и включить базу / по умолчанию /
   • это ваша польза от того, чтобы быть в сопоставимом состоянии. Вы знаете, что по-другому, и вы можете отключить это и диагностировать вещи на основе этого

2. теперь, если у вас есть все основные версии в основном дереве в вашем репо, отмеченном или разветвленном отдельно, то получение версии выше – это просто команда: git merge «magento-vhateverthenextversionis»

   • снова после выполнения этого «git status> changes.txt» предоставит вам список всех измененных файлов между вашими версиями
   • выполнение сайта в браузере будет выполнять обновление, и поскольку вы используете тему по умолчанию, и никакие настройки не активируются, она будет действовать как шарм
   • повторите обновление версии по версии и сохраните состояние вашего кода путем пометки в ветке тестирования или создайте новую ветку для каждой версии на основе существующей ветви тестирования, таким образом вы сохранили чистое состояние для каждой версии пурпурного, которую вы обновили между
   • снова дополнительный бонус здесь заключается в том, что если вы сделаете это с контролем версий, вы также избавитесь от файлов, которые отбрасывают новые версии, и вы можете легко их удалить

3. если вы повторили 2. до нужной версии magento до последней, то пришло время съесть «s * it», который вы унаследовали, и выполните следующие действия:

   • проанализировать все расширения, которые у вас есть, и посмотреть, могут ли они быть обновлены, если вы можете обновить и включить, если они работают с темой по умолчанию
   • diff каждый ядро ​​переписывает в app / code / local / Mage против его оригинальной версии в новой форме из app / code / core / Mage. Вы можете использовать инструменты diff, такие как winmerge.org или изменения (независимо от того, какой os и инструмент вы предпочитаете) по одному или разные целые папки
   • то же самое происходит с вашим шаблоном и перезаписанными шаблонами или макетами. COmpare к оригиналу и объединить свои изменения в новый базовый шаблон и избавиться от старого DOM
   • включить изменения темы и расширения один за другим и отладить

4. если вы доберетесь до этого момента, тогда вы выполнили работу, зависящую от того, как запуталась установка, это может занять несколько дней. Но теперь у вас есть чистое сердцевина magento, контролируемое версией, разделенные перезаписи, которые объединены и просмотрены, и все материалы в отдельной теме, которые можно отключить.

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

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

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

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

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

1. Вы будете контролировать все обычное поведение без сюрпризов
2. Вы будете уверены в здоровой кодовой базе одного происхождения
3. В какой-то момент клиенту вы становитесь владельцем кода , а белый или позитивный подход к реинтеграции настроек кажется лучшим способом убедиться, что ваше владение – это то, что вы ожидаете.

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

Теперь, когда у вас есть безопасная копия веб-сайта, доступного вам для игры, теперь начинается самое интересное.

Первое, что я хотел бы сделать, это вытащить копию запатентованной версии Magento, в которой вы работаете. Сделайте diff on / app / code / core между версией запаса и тем, что у вас есть. Это скажет вам, каковы ваши разногласия. Я бы постарался сохранить все функциональные возможности, которые у вас есть в настоящее время, при этом восстановление ядра в порядке.

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

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

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

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