Magento2 - локальне / постановочне / розгортання виробництва та gitignore

Це може бути одним із видів дискусій, а не питанням.

Я хотів би знати, яку політику розгортання ви дотримуєтесь у Magento2 & local > staging > виробничі середовища

Після кількох спроб ми вирішили, що найкращим (або, принаймні, найбільш солідним) підходом буде цей файл gitignore, включаючи папку vendor у git.

.DS_Store
/.buildpath
/.cache
/.metadata
/.project
/.settings
atlassian*
/nbproject
/sitemap
/sitemap.xml
/.idea
/.gitattributes
/app/config_sandbox
/app/etc/config.php
/app/etc/env.php
/app/code/Magento/TestModule*
/lib/internal/flex/uploader/.actionScriptProperties
/lib/internal/flex/uploader/.flexProperties
/lib/internal/flex/uploader/.project
/lib/internal/flex/uploader/.settings
/lib/internal/flex/varien/.actionScriptProperties
/lib/internal/flex/varien/.flexLibProperties
/lib/internal/flex/varien/.project
/lib/internal/flex/varien/.settings
/node_modules
/.grunt
/pestle.phar
/pub/media/*.*
!/pub/media/.htaccess
/pub/media/catalog/*
!/pub/media/catalog/.htaccess
/pub/media/customer/*
!/pub/media/customer/.htaccess
/pub/media/downloadable/*
!/pub/media/downloadable/.htaccess
/pub/media/import/*
!/pub/media/import/.htaccess
/pub/media/theme/*
/pub/media/theme_customization/*
!/pub/media/theme_customization/.htaccess
/pub/media/wysiwyg/*
!/pub/media/wysiwyg/.htaccess
/pub/media/tmp/*
!/pub/media/tmp/.htaccess
/pub/media/captcha/*
/pub/static/***
!/pub/static/.htaccess

/var/*
!/var/.htaccess

.unison*
/sync.sh

Таким чином, ми запускаємо композитора лише в локальному середовищі: оскільки будь-яке нове розширення або оновлення програмного забезпечення тестується в локальному, потім перевіреному та здійсненому. Ми, мабуть, тоді також включимо файл app / etc / config.php у git, але цей файл перезаписується під час запуску setup:upgrade, правда?

У тому числі розмір сховища постачальника буде більшим, ніж (можливо) рекомендованим, але таким чином, розгортаючи код, ми просто запускаємо послідовність:

bin/magento setup:upgrade
bin/magento setup:di:compile (optional)
bin/magento setup:static-content:deploy

Пов'язана інформація: http://www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

Подивіться, чому ми вибираємо команду компіляції як необов'язковий Magento 2 - setup: di: compile ?

ОНОВЛЕННЯ

Правда, у нас виникають деякі проблеми при розгортанні змін коду в наших опублікованих проектах Magento 2

Зміни працюють у локальній та інсценізації (перевіряється в обох режимах: розробник та виробництво ... хоча ми концептуально налаштовуємо це середовище у режимі розробника), але деякі з них не працюють у виробничому середовищі (у режимі виробництва) тощо ... тож я не впевнений, що ми дотримуємося правильної стратегії. Я хотів би побачити, яка відповідна послідовність команд, і відповідність порядку в цих командах

Насправді щодня я все менше переконуюсь у корисності режиму виробництва Magento 2, якщо тільки ви не збираєтесь нічого змінювати в проекті. Ви можете змінити свою думку?

Насправді щодня я все менше переконуюсь у корисності режиму виробництва Magento 2, якщо тільки ви не збираєтесь нічого змінювати в проекті. Ви можете змінити свою думку?

Я не впевнений, чи розумію ви правильно, але саме для цього призначений режим виробництва : виробничі системи, де ви нічого не змінюєте (код мудрий). До наступного розгортання, тобто.

Я вважаю розгортання на основі Git, що ви використовуєте менш підходящий для Magento 2, ніж це було для Magento 1, через всю попередню обробку. Складання та розгортання складніші, і IMHO не може обійти автоматизований процес збирання

Що я б рекомендував:

• Майте повторювані розгортання, тобто ви повинні бути впевнені, що точно такий же код виявиться у виробництві, яке було в стадії, включаючи створені файли .

• Для цього відокремте збірку від розгортання та виконайте наступне в процесі збирання:

  • composer install( vendorзамість цього можливе також додавання до сховища, але якщо ви це зробили просто для того, щоб уникнути запуску композитора на сервері під час розгортання, скоріше зробіть це на етапі збирання та зберігайте лише composer.lockу репо)

  • Генерація коду (YMMV):

    bin/magento setup:di:compile
    bin/magento setup:static-content:deploy

  • створення архіву ( збірки артефакт ) з повного каталогу Magento, за винятком mediaі var, в тому числі , але vendor, pub, var/generatedі var/di. Починаючи з Magento-2.2 , var/generatedі var/diпереміщаються generated/codeі generated/metadata, що робить його легше відокремити їх від решти з varяких повинні враховуватися при розгортанні.

• У процесі розгортання скопіюйте артефакт збірки на цільовий сервер, витягніть його в новий каталог і:

  • зв'язати постійні каталоги в нього ( media, var/session, var/log...)
  • включити режим обслуговування
  • переключити корінь документа (зазвичай docroot є символьним посиланням на останній випуск, змініть його на новий випуск)
  • промити кеш
  • бігати setup:upgrade
  • відключити режим обслуговування

• Цей процес розгортання може бути легко реалізований за допомогою Deployer , який схожий на Capistrano, але в PHP. Повне рішення для розгортання Magento 2 на базі диспетчера можна знайти тут: https://github.com/mwr/magedeploy2 (завдяки netz98!), А ось ще одне, яке ми використовуємо: https://github.com/staempfli / magento2-розміщення-інструмент

• Зберігання app/etc/config.phpв сховищі добре відстежувати включені та відключені модулі.

Це не покрокова інструкція, але вона повинна дати вам огляд більш надійної альтернативи вашому поточному процесу. Погляньте на пов'язані інструменти, щоб побачити, як може виглядати повноцінне рішення.

На мій погляд, зачекайте Magento 2.2 або спробуйте застосувати подібний підхід.

Magento 2.2 запроваджує розгортання конвеєра , наприклад, розділяючи сервер збірки з виробничим сервером.

Ось офіційна документація: http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

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