Керування Magento / Композитором / Розгортанням

Тож мені подобається використовувати інсталятор hackathon Magento Composer, але я намагаюся зрозуміти, як інші користуються ним стосовно служби розгортання. В даний час я використовую DeployHQ, і так, я можу встановити його для розгортання та запуску композитора, коли є оновлення до репо, але це для мене зараз не має сенсу.

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

Коли я оновлюю свою тему або спеціальне розширення (на яке посилається у файлі json), немає "гачка" для оновлення служби розгортання. Тому я повинен увійти на свій сервер і вручну запустити композитор (який знімає сайт до його закінчення).

То як іншим керувати цим? Чи слід запускати композитор лише локально і включати папку постачальника в репортаж?

Будь-які відповіді будуть дуже вдячні.

Я створив структуру в нашому агентстві, яка дозволяє нам використовувати 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.
• Папка постачальника виключена з Git, але файл composer.lock включений.

Розгортання

• Ми розгортаємо за допомогою Capsitrano, який дозволяє використовувати декілька серверів додатків та середовищ (постановка / виробництво)
• Capistrano будує всю базу коду на сервері в новій папці, а потім міняє симпосилання webroot у самому кінці, тобто немає простоїв для вашого веб-сайту.
• Capistrano працює composer installпід час збирання та розгортає всі модулі в підмодулі 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 .. Це розробка його першого підходу

Важливо розуміти, що Composer - це не інструмент розгортання, а інструмент розробки.

Існують різні підходи, як підготувати розгортання з усіма залежностями:

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

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

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

• srcмістить усі конкретні модулі проекту. Композитор також встановлює тут будь-які інші модулі Magento
• .modmanпосилання на srcтак, щоб модман легко впорався з символікою
• wwwє веб-корінь. Композитор встановлює тут ядро ​​Magento

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

• srcмістить усі конкретні модулі проекту. Щоб включити їх .modmanтак, щоб модман створював посилання, використовуйтеmodman link
• .modmanзнаходиться в .gitignore. Композитор встановлює тут модулі Magento
• wwwє веб-корінь. Композитор встановлює тут ядро ​​Magento