Управление Magento / Композитор / Развертывание

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

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

Когда я обновляю свою тему или пользовательское расширение (на которое есть ссылка в файле json), нет «ловушки» для обновления моей службы развертывания. Поэтому я должен войти на свой сервер и вручную запустить composer (который отключает сайт до его завершения).

Так как другие справляются с этим? Должен ли я запускать composer только локально и включать папку vendor в мое хранилище?

Любые ответы будут с благодарностью.

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

Структура хранилища

Ниже приведена структура папок «родительского» хранилища. Он содержит компоновщик JSON и блокирует файлы и другую конфигурацию, необходимую для развертывания.

- code
   - magento
- deployment
- environmental
   - local
       - local.xml
       - robots.txt
   - staging
       - local.xml
       - robots.txt
   - production
       - local.xml
       - robots.txt
- provisioning
- public
   - index.php
- vendor
- composer.json
- composer.lock

• Все индивидуальные настройки клиента хранятся в отдельном модуле «настройки», который устанавливается с помощью Composer.
• Ядро Magento включено как подмодуль Git ( code/magento)
• Пользовательские index.phpи другие папки, такие как мультимедиа и ошибки, находятся в общей папке за пределами корня Magento.
• Файлы среды (local.xml, robots.txt и т. Д.) Вставляются в корневой каталог Magento в процессе развертывания.
• Папка vendor исключена из Git, но включен файл composer.lock.

развертывание

• Мы разворачиваем, используя Capsitrano, который позволяет использовать несколько серверов приложений и сред (подготовка / производство)
• Capistrano собирает всю кодовую базу на сервере в новую папку, а затем переставляет символическую ссылку webroot в самом конце, что означает, что для вашего сайта нет простоев.
• Capistrano запускается composer installво время сборки и развертывает все модули в подмодуле Magento.

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

Другой метод заключается в использовании стратегии развертывания копии хакатонов magento, которая выглядит примерно так в вашем файле composer.json:

"extra": {
    "magento-root-dir": "./",
    "magento-deploystrategy": "copy",
    "magento-force": true
}

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

Я не большой поклонник извлечения из сторонних репозиториев, когда вы собираетесь делать живое развертывание, и зависеть от сторонних репозиториев довольно рискованно, если у вас нет какого-то прокси-кэша для вашей сети ,

Прочитайте эту статью, и она даст вам другую точку зрения: http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_debacle

По сути, NPM вышел из строя (вроде ...), и все системы сборки перестали работать (для критических развертываний!), Потому что они напрямую зависели от NPM. (NPM похож на Packagist для Javascript, за исключением того, что NPM фактически содержит файл, а Packagist просто указывает на репозитории модулей Github - поправьте меня, если я ошибаюсь)

редактировать: только красный ответ fschmengler .. Это развитие его 1-го подхода

Важно понимать, что Composer - это не инструмент развертывания, а инструмент разработки.

Существуют разные подходы к подготовке развертывания со всеми зависимостями:

• зафиксировать каталог вендора (или там, где композитор устанавливает источники) в хранилище проекта
• используйте сервер сборки, который запускается composer installи создает архив с результатом, который вы можете развернуть повторяемым на разных целевых системах
  • работает composer installна сервере, а затем переключает символические ссылки, как предложено @ jharrison.au, является вариантом этого

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

Моя текущая структура проекта выглядит следующим образом (с использованием альтернативных инсталляторов компоновщика AOE ):

• srcсодержит все специфичные для проекта модули. Composer также устанавливает любые другие модули Magento здесь
• .modmanссылки на srcтак, чтобы модман мог легко обрабатывать символические ссылки
• wwwэто корень Composer устанавливает ядро ​​Magento здесь

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

• srcсодержит все специфичные для проекта модули. Чтобы включить их .modmanтак, чтобы modman создавал символические ссылки, используйтеmodman link
• .modmanнаходится в .gitignore. Composer устанавливает модули Magento здесь
• wwwэто корень Composer устанавливает ядро ​​Magento здесь