В свете вышедшей в свет новой версии Magento — 2.2.0, решил выложить свой персональный опыт развертывания приложений на базе этой платформы. В статье описывается развертывание приложения именно для разработки модулей, а не для эксплуатации магазина (как говорится, технарям от технаря).  После довольно продолжительного эволюционирования скриптов автоматизации процесса развертывания Magento у меня сложился следующий набор, который я оформил в виде sample-проекта: flancer32/sample_mage2_app. Проект поднимает приложение для разработки публичного модуля "flancer32/mage2_ext_login_as" (выложен на Packagist'а) и "приватного" модуля "flancer32/sample_mage2_mod_repo" (доступен только с GitHub'а). Скрипты были созданы и проверены под Ubuntu 16.04 / PHP 7.0.22 / Composer 1.5.2. Используемые в скриптах программы (php, composer, mysql, patch, ...) должны быть установлены глобально. Должен быть настроен доступ через Composer к соответствующим репозиториям (Magento и Github — файл ~/.composer/auth.json):  Просьба создавать собственные параметры доступа и не использовать значения из примера. В самом общем случае Magento-приложение состоит из следующих частей: Состав приложения задает последовательность рутинных действий, сводимую в общем случае, к следующей: Все развертывание производится при помощи shell-скриптов, которые можно разделить на три группы: Скрипты написаны не в стиле user friendly, а скорее в стиле friendly user — проверка входных параметров и совместимость запрошенных режимов работы друг с другом сведена к минимуму. Предполагается, что пользователь, запускающий скрипт развертывания с указанием параметров, понимает, что они означают и как они совместимы друг с другом. deploy.sh Его задача — определить режим развертывания приложения, подгрузить конфигурацию развертывания и запустить рабочие скрипты в соответствии с заданным режимом. Параметры запуска deploy.sh: Развертывание приложения без инициализации базы данных (база инициализируется через Web UI): Развертывание приложения с сохранением существующей базы (при повторном развертывании, например): Развертывание приложения с переводом Magento 2 в production mode (если мы разрабатываем API, например): Режим развертывания live предназначен при развертывании приложения для использования в качестве магазина и в данном примере не рассматривается. cfg.init.sh Параметры развертывания приложения прописываются в обычном shell-скрипте в виде переменных окружения. Шаблон (cfg.init.sh), содержащий все доступные переменные, копируется вручную в конфигурационный файл, соответствующий режиму развертывания (cfg.work.sh или cfg.live.sh), и заполняется соответствующими параметрами. Рабочие скрипты содержат практически идентичный заголовок, позволяющий и Здесь все просто — запускается конфигурационный скрипт, который задает соответствующие переменные окружения: deploy/bin/app/mage.sh: По большому счету все сводится к созданию в соответствующем каталоге (work)  приложения через Composer: Таким образом, корневой каталог для конфигурации web-сервера: ${DIR_ROOT}/work deploy/bin/app/own/work.sh Эта часть процесса зависит от режима развертывания. Сначала донастраивается дескриптор развертывания приложения (work/composer.json) — здесь важно обратить внимание на версию Composer'а (например, на старых версиях не работает composer config minimum-stability): затем устанавливаются нужные версии нужных модулей: В данном случае мы подключили к приложению два модуля для разработки: Остается указать IDE, что данные модули находятся под контролем версий:  Опционально можно применить патчи как к сторонним модулям (как в случае с flancer32/sample_mage2_mod_zip, установленном из zip'а), так и к исходникам самой Magento (в последнее время Magento Team значительно улучшила работу с правками, но все равно бывает необходимость применить известную "таблетку", которая не вошла в крайний релиз): В данном случае патчится сторонний модуль flancer32/sample_mage2_mod_zip, в который добавляется порядок загрузки: deploy/bin/app/db/work.sh
Также зависит от режима развертывания и от ключей запуска deploy.sh. Возможен вариант, когда нужно пересоздать базу: или просто подключить приложение к существующей базе: После подключения приложения к базе можно произвести донастройку базы. Например так: В версии 2.2.0 есть возможность прописывать параметры конфигурации через CLI, но напрямую в базе можно задавать не только эти параметры, но и многое другое (например, задавать налоговые ставки). В общем случае, при развертывании магазина с темой, требуется инициализация медиа-файлов (из backup'а или клонирование с эталонного сервера). При разработке модулей этот шаг можно пропустить. Пропускаем. Финализацию можно разбить на две части: специфичная для режима развертывания и общая. deploy/bin/app/final/work.sh В зависимости от режима можно выполнять перевод приложения в developer/production mode, включать/отключать кэш, проводить компиляцию кода: и запускать команды установленных модулей: В конце желательно запустить хоть раз cron и выполнить переиндексацию (чтобы сократить ругань в админке): deploy/bin/final.sh Общая финализация развертывания включает в себя установку прав доступа к файлам: Описанный в статье процесс развертывания приложения на базе Magento 2 не является универсальным и может модифицироваться в зависимости от проекта. Как говорилось в древние времена, очередную версию Windows можно начинать использовать после выхода второго сервис-пака. Всех причастных — с выходом Magento 2.2.0! А Magento Team — стойкости и оптимизма в этой безнадежно проигранной борьбе с непреодолимой сложностью кода и вероломством требований!!! wiredgeese.com