Magento без сомнения является выдающейся системой для построения e-commerce приложений. Принципы, заложенные в ее архитектуру, позволили не только занять первое место рейтинга в своем классе web-приложений и удерживать его многие годы, но, что более важно, сформировать вокруг себя эко-систему разработчиков, создающих для основного функционала расширения, удовлетворяющие самым экзотическим требованиям пользователей. Но вот чего мне сильно очень сильно не хватало в Magento при первом «подходе к снаряду», так это системы логирования уровня Log4php. Поэтому первое расширение, которое было сделано для Magento — это «обертка» для Log4php. Под катом описание того, как мы используем эту «обертку» в наших Magento-проектах.

При развертывании Magento-приложений с использованием Magento Composer столкнулись с проблемой, что различные экземпляры одного и того же приложения (девелоперский, тестовый и т.д.) должны использовать различные локальные настройки (например, параметры подключения к БД). До этого, в другом проекте, использовался подход, когда в приложении (под контролем версий) находятся шаблоны конфигурационных файлов с placeholder'ами и скрипт, замещающий placeholder'ы локальными значениями и копирующий результат в нужное место. Локальные значения хранились отдельно для каждого экземпляра по месту развертывания. Хотелось привычный подход сохранить и для нового метода развертывания. Поиск устраивающего плагина на packagist.org завершился ненахождением, в силу чего и родилась идея сделать подобный плагин самостоятельно. При создании плагина пришлось надергать информацию из различных источников — информации с сайта Composer'а по плагинам оказалось недостаточно. Что и привело к написанию этой статьи.

Введение

В статье описан опыт развертывания девелоперской версии Magento-приложения с использованием Magento Composer'а. Структура типового Magento-приложения в нашей компании:

• Magento
• Сторонние модули, используемые в проекте
• Разрабатываемые нами модули, используемые более, чем в одном нашем проекте
• Разрабатываемый нами модуль, содержащий функционал конкретно для данного проекта
• Тема для конкретного проекта

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

В связи с началом нового проекта для развертывания Magento-приложений решили попробовать Magento Composer. На данный момент у нас код каждого проекта хранится в своем SVN-репозитории, плюс в отдельном — все разрабатываемые нами модули (как общие, так и специализированные):

• инсталляция Magento и сторонние модули для проекта 01;
• инсталляция Magento и сторонние модули для проекта 02;
• ...
• наши модули;

Для использования Magento Composer'а проект разделили на следующие части (каждая в своем git-репозитории):

• z_mage_composer_prj_01_full: скрипты развертывания всего проекта, тема, сторонние модули, не доступные через Magento Composer;
• z_mage_composer_mod_01: первый модуль, от которого зависит проект;
• z_mage_composer_mod_02: второй модуль, от которого зависит проект;

Введение

При развертывании проектов основанных на модульных приложениях (например, Magento) сталкиваешься с тем, что в проекте сосуществует код, находящийся в различных репозиториях. PhpStorm вполне хорошо справляется с подобной ситуацией. Допустим, у нас есть основной проект, расположенный на Github'е, в котором используются один новый модуль, расположенный там же, и один legacy-модуль, расположенный в SVN-репозитории:

• основной проект: https://github.com/praxigento/z_git_submodules_main.git (Git)
• новый модуль: https://github.com/praxigento/z_mage_composer_mod_01.git (Git)
• legacy-модуль: https://github.com/praxigento/z_mage_composer_mod_02/trunk (Git as SVN)

Работать одновременно с несколькими git-репозиториями позволяет механизм git submodules, а PhpStorm также позволяет к этому добавить и SVN-репозиторий.

Возникла задача плавной миграции с рабочей станции под Windows на Ubuntu. Так как выполнение основных действий при помощи компьютера никто не отменял, то миграцию приходится делать кусками, оставляя доступной привычную среду (Windows 7 x64). Так как я являюсь разработчиком, то первым делом нужно переносить IDE (в моем случае — PhpStorm). Целевой машиной для переноса был выбран виртуальный хост hamster, работающий под Ubuntu, на котором тестриуются наши проекты.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.1 LTS
Release:        14.04
Codename:       trusty
$ uname -a
Linux hamster 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 1